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(57) Abstract 

A system and method for conducting electronic payment transactions accepts and stores information describing an item sold by a 
merchant on a commerce server. The merchant also defines payment processing rules that define the payment methods accepted by the 
merchant. The merchant, in tum, is provided with a reference identifying the commerce server and the item. The merchant preferably 
publishes this reference at the merchant's web site on a web page offering the item for sale. A customer viewing the merchant's web site 
indicates a desire to purchase the item by selecting the reference. As a result, the customer is put in contact with the commerce server and 
is provided with information from the commerce server about the item and is given a list of payment options. The customer preferably 
selects a payment option and provides the commerce server with payment information, such as a credit card number. In response, the 
commerce server contacts a selected payment system and completes the electronic commerce transaction. The commerce server then notifies 
the customer and the merchant of the results of the electronic commerce transaction and delivers the item to the customer. 
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Background 

Field of the Invention 

This invention pertains in general to electronic commerce and in particular to a method 
10 and system for conducting electronic payment transactions via the Internet. 

B ACKCROUND OF THE INVENTION 

Electronic commerce conducted over the Internet has become increasingly important 
over the last decade. Online merchants offer goods and services for sale or rent including 

15 physical objects such as compact disks, books, and clothing, and intellectual property such as 
streaming music and movies and electronic books. Physical items may be delivered to the 
customer via the mail or a variety of other shipping options. Intellectual property, in contrast, 
may be delivered to the customer by allowing a download via the file transfer protocol 
("FTP"), providing the customer with an access key, establishing a telnet session, or through 

20 some other form of electronic delivery. 

Typically, these goods and services are displayed on the merchant's web site and a 
prospective customer views, selects, and purchases the goods using web browsing software 
such as NETSCAPE NAVIGATOR* The customer usually pays for a product by establishing 
a secure connection with the merchants web server and transmitting payment information, 

25 such as a credit card number, to the merchant. The merchant then uses back-end processing to 
verify the payment information and receive payment. For example, the merchant may use a 
secure telephone line or network link to contact the credit card issuer before accepting the 
customer's order. Eventually, the merchant and credit card issuer settle payment and the 
merchant delivers the product or service to the customer. 

30 A difficulty with the above-described scenario is that each merchant must implement an 

inventory and payment database and a payment acceptance and verification system, For 
example, the merchant must establish and maintain a database tracking sales, delivery, and 
payment information and product inventories in order to support the electronic commerce 
system. There is significant cost and complexity in maintaining this database, including the 

35 difficulty of integrating it with legacy accounting and fulfillment systems and aggravated by 
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The United Parcel Service has ac- 
tivated the first nationwide mo- 
bile data service using cellular 
technology, permitting the 
company to transmit delivery infor- 
mation from its 50,000 delivery vehi- 
cles for immediate customer access. 

UPS created the system by form- 
ing the first alliance of fifty public 
cellular carriers throughout the 
country to provide a common data 
service, all connecting with UPS's 
own private global telecommunica- 
tions network, UPSnet The system, 
which was implemented at a cost of 
about $150 million, is the largest of 
its kind in the world. UPS selected 
cellular over the other network alter- 
natives because it provided the most 
extensive geographic coverage, high- 
est reliability, and potential for fu- 
ture upgrades. 

The cellular alliance features 
McCaw Cellular Communications, 
Contel Cellular, GTE Mobilnet (for- 
merly known as GTE Mobile Com- 
munications), PacTe! Cellular, and 
Southwestern Bell Mobile Systems, 
all competitors in the cellular indus- 



try. These firms enlisted fifty additional 
carriers to help UPS extend its immedi- 
ate tracking network across the United 
States. 

Comprehensive Tracking 

The mobile data service is the founda- 
tion for the company's comprehensive 
tracking system— UPS TotaJTrack, which 
provides immediate delivery information 
on bar coded air and ground packages. 
This information was not previously 
available until the day after delivery. 

UPS is the only parcel delivery com- 
pany able to digitally capture both pack- 
age information and the customer's sig- 
nature through a custom-built hand held 
computer called the DIAD (Delivery In- 
formation Acquisition Device) . Access to 
the cellular system is activated when the 
UPS driver inserts the DIAD into the ve- 
hicle's unique transmitter (DIAD Vehi- 
cle Adapter). From there, the tracking 
information is uploaded through the cel- 
lular system and UPSnet to the UPS Data 
Center in New Jersey. The in-vehide * 
equipment and logistical support came 
from Motorola, Inc., with instaJlation by 
UPS's automotive mechanics. 



This cellular network pro- 
vides the connection between 
UPS vehicles and the UPSneL 
These systems are created to be 
fail-safe with cellular redundan- 
cies, dual access to UPSnet. and 
multiple connections to the data 
system. 

The cellular-based wireless 
data service provides immediate 
access to delivery information for 
more than I million UPS daily 
pickup customers. It also provides 
more extensive geographic cover- 
age than any mobile communica- 
tion alternative. 

The UPS mobile data system 
includes several technical innova- 
tions designed to adapt the voice- 
oriented cellular systems for data 
transmission. Error-correction com- 
munication protocols are used to 
ensure error-free message delivery. 
And ceUular carriers' switching sys- 
tems are directly connected to UP- 
Snet to reduce the duration and 
cost of data calls. The carriers also 
developed a billing system consoli- 
dating all carrier charges into a sin- 
gle UPS bill and 
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established a unified earner help desk that 
resolves service problems quickly. 

With the cellular communications 
technology. UPS TouTTrack can proxide 
detailed information on such thing? as 
pickup date, scheduled date of delivery 
wrui of package, same day verification 'of 
debvery, and the name of the person who 
received the package, ft is available bv caU- 
mg a toU^-ee Tracking Hot Line (NS00- 
457-4022) which is staffed tweniv-four 
hours a day, seven daw a week. 

New levels of Service 



fn addioon to providing customen with 
immediate tracking information. ITS is 
able to provide customers with 
MaxiShip. a PGbased automated 
shipping system designed for cu> 
tomers with high package volume 
and the need for fast package pro- 
ceasing. Vsing UPSprovided soft- 
warc « trie system automatically 
rates and zones packages, prepares 
packages requiring special services, 
such as CO D. and Delivery Con- 
firmation, and creates user<iefined 
management reports. 

UPS has also created a new 
level of service that provides guar- 
anteed three-day delivery and im- 
mediate package tracking. Called 
UPS 3 Day Select, it is the Snt service of its 
kind to be offered in the small package dis- 
tribution industry. UPS 3 Day Select was 
developed primarily for Ionger<iistance 
shippers who need time^iefinite delivery 
and higher levels of information. The ser- 
vice is available to anv shipper for interstate 
delivery throughout the 46 contiguous 
states and is priced between (he company's 
tradioonal ground and air express services. 

UPS 3 Day Select can be used when a 
long distance shipment must be delivered 
fester than regular UPS ground service. 
Customers are provided with special bar- 
coded labels, each with a unique number 
that is scanned into the tracking svstem at 
key points during transit. For immediate 
updates on a shipment's status, customers 
can call the Ticking Hot Line and pro- 
vide UPS with the tracking number. 

The cellular system developed by 
UPS is considered the most comprehen- 
sive wireless data transmission architecture 



available today. It covers more area and is 
more reliable than any other type of mo- 
bile communication. 

Technology has also provided UPS 
key platforms for expanding its customer 
services globally. In 1988 UPS moved into 
die overseas market with its global elec- 
tronic data communications network. UP- 
Snet. to serve as the information process- 
ing pipeline for international package 
processing and delivery. LTSnet now has 
more than 500,000 miles of lines and links 
more than 1,300 UPS distribution sites in 
forry*x countries. UPS is leasing excess 
lines through a UPS owned company, 
UPS Telecommunications. 

In 1991 UPS's International Ship- 



Cellutar Indusiry Fods of a Glance 

JSp^ ° n 0d * ef 13tf1 < !983 < -toceMar 
sysiem Deg 0n operating in Ortega 

Subscriber 10 million, as of November 23. 1992. 
Growth, current adding 222,000 new cellular users 

SSff^ m f* nausf W^ed from 20S00 
juoscribers fo 10 million. 

Revenue. Approximate y $ 7.2 billion 0 year. 



mcn t Processing System (ISPS) received 
the COMPUTEKWORLD/Smithsonian 
award for innovation in information tech- 
nology. 

Smart Scanning 

Since 19S9, ISPS has acquired a universal 
accounong system and an enhanced 
tracking system that can follow the move- 
ment of a package in transit. Everv inter- 
naoonal package now undergoes "sman 
sinning" which takes tracking to the 
next step by determining through bar 
code technology not only where the pack- 
age ^supposed to be, but where it actual- 
7 ?* ^ Icm *° Provide f 0r re . rout . 
•ng of packages and notifies interim and 
final UPS destinations if a package is ear- 

Jv, late, or routed to the wrong destina- 
oon. 

UPS has long been interested in Elec- 
tromc Data Interchange (EDI), the com- 



puter-texornpmer exchange of informa- 
oon. The company has the most extensive 
EDI interaction with foreign customs 
clearance houses in the world, with stan- 
dard-based systems in place or being devel- 
oped in more than twenty countries EDI 
« allowing UPS to streamline procedures 
eliminate paper, and conserve time and ' 
money. UPS is now able to electronically 
disseminate clearance and delivery infor- 
mation from the customer's computer, to 
the destination customs agency, to the ' 
consignee. To support these technology 
systems the UPS maintains two data cerh 
ten. in Mahwah and Paramus. New Jersey 
UTS is not only a global delivery net- 
work, but a telecommunications company 
with its own fiberoptic network and 
its own communications satellite. 
Because, of its recent interest in us- 
ing high technology to deliver pack- 
ages, it is easy to forget that the com- 
pany was founded in 1907 in Seatde. * 
Now headquartered in Atlanta, UPS 
has more than 273,000 employees, 
delivers 1 1 5 million parcels and 
documents per day, owns ] 16,000 
vehicles and 197 jet aircraft Its ser- 
vice area includes more than 185 
countries and territories, has a daily 
customer base of 1.2 million ship- 
pers, and last year earned $ 16.5 bil- 
lion in revenues. 
UPS has 3,000 employees involved 
just in technology, owns six mainframe 
computers, 250 minicomputers, and 
41300 PCs compan wide. It also has 600 
UNs and 18.000 connected workstations, 
100 packet switching nodes worldwide 
and 465.000 miles of dedicated cable cir- 
cuitry. 

UPS s creation ofTotafTrack is seen 
both as a major advance in development 
of the cellular industry and encourage- 
ment for the industry itself to undertake 
other advances in data services. 

The United Parcel Service is in the 
package distribution business and also the 
information business reporting on its 
package business. The ads that UPS is run- 
ning on^behalf of TotaJTrack state that 
"now there's just one thing that travels 
faster than a UPS package. And that's 
news of ic" A happy, and competitive, state 
of affairs. 
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PC Foods, Inc. 

Customer Service Agreement 



P. 1ZZ. 



You, the Customer, and PC Foods mutally agree to be bound by the 

following terms and conditions: 



PC Foods agrees to receive your order, purchase only items 
listed, and deliver them to your designated place of delivery 
within two hours of the time you list on your order as the 
preferred delivery time. This two hour window is the delivery 
time frame. 

All orders received by midnight (est) will be delivered the next 
day within the delivery time frame unless an alternate delivery 
date is specifically requested. Requests for same day delivery 
will be accommodated in most circumstances for an additional 
fee. 

The Customer agrees to be liable for the cost of groceries and 
service fees for the items requested and futher agrees to make 
full payment at the time of delivery. This payment includes the 
grocery total and applicable service fees. PC Foods will accept 
cash, credit card (Visa, Master Card, American Express), 
money orders, or personal checks. A returned check fee of 
$25.00 will be assessed for all returned checks, regardless of 
reason. In the instance PC Foods receives two returned 
checks, a cash-only basis will be invoked. 

The Customer agrees to be available and accept the grocery 
purchase during the delivery time frame. An non-deliverability 
charge of $10.00 will apply if at the expiration of 20 minutes 
past the delivery time frame you or your designate are not 
available to accept the purchase and render full payment. A 
second delivery will be attempted during the same day at a 
reasonable time determined by PC Foods. PC Foods is not 
liable for the freshness or quality of the order past the delivery 
time frame. Due to the perishable nature of the items being 
delivered, when the Customer is not available to receive the 
groceries on the second delivery attempt, the Customer agrees 
to still be liable for all costs and service fees. 



If the Customer fails to pay at the time of delivery or if the 
customer is not available to receive the delivery, the Customer 



Customer service Agreemem 



agrees to bear and pay collection fees and legal fees 
reasonably necessary to collect the original principal amount 
due to PC Foods. 

If PC Foods cannot for any reason meet our obligation for your 
individual order, all reasonable efforts will be made to notify 
you prior to delivery and you may elect to cancel the order 
without any assessed service fees. 

In addition to the above stated contract between PC Foods and 
you the customer governing the terms and conditions of 
receiving merchandise, the following conditions apply to the 
use of the Ordering System. The PC Foods grocery ordering 
system is the sole property of PC Foods, Inc. You may use this 
proprietary system only after completing a registration form. All 
logos, slogans, operational characteristics, posted articles, and 
code - including publically available HTML, Text, JavaScript, bit 
maps, and the "look & feel" are copyright of PC Foods, Inc. and 
Walker Consulting. You may not publish, reproduce, reverse 
engineer, copy, or create derivative works of the PC Foods 
Ordering System. 

By clicking on the "I Agree" button the customer agrees to be 
liable for any use of the PC Foods ordering system by or 
through that customers assigned account number. You the 
customer also agree to inedemnify PC Foods for any such use. 
PC Foods may alter any terms of this agreement in its sole 
descretion by giving the customer reasonable notice. The 
customer will be deemed to have accepted such changes 
through continued use of the PC Foods ordering system. The 
customer may terminate this agreement by giving PC Foods 
reasonable notice and agrees to be liable for any charges 
incurred. Finally, the customers agrees to provide truthful and 
accurate information on the registration agreement. Failure to 
do so will lead to the termination of your account and possible 
legal action for violation of these agreement terms. 

HAVING READ AND UNDERSTOOD IN FULL THE 
FOREGOING REGISTRATION & CUSTOMER SERVICE 
AGREEMENT, CONTINUE WITH THE REGISTRATION 
PROCESS BY CLICKING ON Start Registration IN THE LEFT 
FRAME. YOU WILL BE ASK TO SIGNIFY YOUR 
AGREEMENT WITH THESE TERMS BY SELECTING / 
AGREE AFTER FILLING OUT THE REGISTRATION FORM. 
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I. ABSTRACT 

Japan's economy started to slow down in 1991. 
durinq this period overall transportat.on demands were 
down These difficult times affected the Door to Door 
pS Service (DTD), however, we see this busmess 

eXPa FSing the .ead of the U.S.. Japans DTD 
started 15 years ago. Of the 40 compan.es which 
Sed in th. DTD industry only a few 
Amongst these companies. Yamato Transport Co Ltd 
^TC) Japanese Post Office, and Nippon Exp^ssC* 
E. emerged as the industry leaders and ^oday 
command a virtual monopoly. According to the 1991 
Stistics of the Japanese Ministry of Transport, ttese 
22 companies handled 78% from the total 1* bi.hon 
parcel volume. YTC. the Japanese p.oneer and leader, 
delivered 0.5 billion parcels in 1991. 

Japan has 39.000 truck companies and the.r fleet 
consist of ordinary trucks offered by the manufactures^ 
wouW like to explain the history of our custom 
made DTD-Takkyubin truck and .ts mformafon 

tCChn .Seko Yamato Takkyubin" * the name of our 
consumer friendly DTD service, offenng ne* day 
delivery, flat rate, and equal serv.ce to a^*** 
anvwhire YTC uses box containers (Unit Load 
Sm) and Logistic Management to standardize all 
le nd work Our catch phrase is "Call Yamato for a 
pickup tS to deliver tomorrow" and our employee 
Totto'is "Service first and bottom-up-managern n ^ 
Following our mottos we developed the Takkyubm 
truck Eve^r year, improvements, especially in mobjrty 
Sf defcZJ Unctions, are added to our "Infomob i 
hteqSed ^adio and YTC network, combined w.th 
SmSd functionality, all part of 

t ^ qcT ne No U tru C S —u ^ C S " 
Sn truc^ advanced integrated communication 
technology i.e. an office on wheels. The s where YTC 
Seooed in and implemented a technologically 
advanced "uck which allowed us to lead the industry. 



(2) 

II. DTD PARCEL DELIVERY 

In 1977 YTC pioneered Japanese DTD. By 1991 
the totaf industr;. including Post Office services 
delivered about 1.53 billion parcels annually. 

Parcels Delivered / Annual Increase 
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YTC N'tDDon Express Co., Ltd, and the Post Office 
^T^Si of 740/. The parcel jj*mj 
increases annually and the three compan.es have 
virtual DTD-monopoly. 

Annual Parcel Delivery 




Figure 2 
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In the United States where the business started 10 
years earlier than in Japan, companies such as United 
Parcel Service (UPS), DHL, and Federal Express carry 
more than three billion parcels annually. They 
expanded their business world-wide and share now 
more than 60% of Japan's international parcel volume. 
YTC started a joint venture with UPS, DHL founded 
DHL Japan with support from Japan Airline and 
Lufthansa, and Federal Express bought a Japanese 
transport company. 

U.S. DTD - Parcels are picked up by truck and 
delivered to the local hub close to the airport. A hub is 
basically a truck terminal with a high speed sorting 
machine. Parcels which are to be delivered over long 
distances, are flown to Super Hubs via company plane. 
UPS has its Super Hub in Louisville. KY, and Federal 
Express in Memphis, TN. The last parcels arrive 
around midnight. All the sorting is done in a few 
hours. The parcels are then flown to their destination 
hub, to be picked up by trucks and delivered early in 
the morning. This system is called Hub and Spokes. 

Hub and Spokes 



«— ♦ : Airplane 




Figure 4 Figure 5 

According to business reports from UPS and 
Federal Express, their air fleet consists of more than 
300 large body planes. Both companies Super Hubs 
are in the central part of the U.S., and the time zones 
are used effectively. The dynamic super hub system 
has been very successfully implemented. 

Japan's land area is 380,000 square kilometers 
(146.000 square miles), which equates to be 1/25 of 
the U.S.. Japan has four main islands and over 4,000 
smaller islands. The boomerang shaped archipelago 
stretches 2.800 kilometers from north to the south-west. 
The majority of the population lives in the densely 
populated metropolitan areas of Tokyo and Osaka, 
barely 500 kilometers (312 miles) apart. Between these 
two cities the parcel volume is extremely high. On the 



other hand, the parcel volume for the spars* 
populated poles of the country is very low. 4 ^ 

Due to Japan's unique geographic ai 
demographic features, the american Hub and Spo 
system with its heavy reliance on cargo planes coi 
not be implemented and thus a considerably differe 
DTD derived. 

In - 1991, according to Japan's Distribute 
Statistics, the total weight of parcels delivered 
domestic transportation was 6.3 billion tons. T 
trucks share is 57 billion tons or 90%. Multiplying t 
weights by the delivery distances, trucks account 
more than 50% weight-distance. Maritime and i 
transportation accounts for almost all other pan 
cargo movement, air cargo accounts for less than 1°/ 

Japan has 5,000 kilometers (3.125 miles) 
expressways covering the country. Tunnels a 
bridges for rails and expressways connect Honshu w 
Hokkaido. Shikoku, and Kyushu. The excellent ro 
and track infrastructure is capable of handling lar 
volumes of cargo. YTC's transportation system tak 
advantage of this by utilizing 11 -15 ton trucks 
ensure fast parcel delivery. The most striki 
difference between the U.S. counterparts, is the virti 
aversion of planes. YTC has a hub in every large ci 
a total of 64. Most hubs have 63 truck routes to 
other hubs. One circum-route provides additioi 
support. In Japan, this system is called rosenbin. 1 
actual rosenbin truck routes exceed 2,200. 



Rosenbin Routes 

«— * : Resent i 




Figure 7 

Around midnight rosenbin trucks leave for \ 
destination hubs where they arrive in the early mornn 
To increase efficiency the truck routes are support 
with airplanes, trains and piggybacks. Sorting is dc 
in a few hours and morning delivery starts. Each i r 
sized hub supports 20 to 25 pickup and deliv 
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"flZ .rt oSS up pa-e B . in «*»».. 
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f he 7r share reached 10%. This new generation of 

Takkvubins became an instant success. 

T Me^ore than 20 years of Pl^^SS' 

Takky The n f'ftefyears of YTC's expansion were 
h rid taoe No specific DTD regulations 
hampered by red tape n P <or 

were enacted, and YTC tad nc PP y (afgef 

""h T.fc me Japanese Government acted, 
and finally in 1989. me j thejr 

de !ThTre Aftt' imptme^ng a system tailored to 
anywhere. After imp s - g _ success 

surpassed by the U.S.. 

HI. TAKKYUBIN CUSTOM TRUCK 

YTC started as a regular truck height company 

SST in ^ ^one incident changed everything. A 
delrvery. In ° ups deBvery truC k. triggered 
picture showing a brown uro , rea | ize d that a 

rstSis ~ * 

servic ; t s2S^^*^^ desi9n ?, 

, n «i52 ^ delivery trucks, followed by successful 
SSSS STU included handling, effects 



neS s. safety and -human^ ^^hic^ 

ssfis -TSc? £ V,sssr s 

presented it to Yamato's truck man ^ 

concept was ^^^r^SK^d to build five 
Corporation approached YTC and one 
prototypes of a Takkyubm truck. In W w 
Takkyubin truck was delivered. The cost g 
abou! 60.000.000 yen W^USJ^ it ™alk 
realizing the line. The 

Trough Truck' and added .1 : tt> its p ^ 
truC k allowed the drrver to walk -n up ,ght P 
tne cabin to the cargo area^ Theta* 
critics. A raw and sometimes b 
combined w*h " ^team spirit faced 

rctaK» £ 

9 .450 are currently* M*™*^ the driver's 
The "Walk Through T ruck Jhe truck ta 

U.^K tech ow emissTon diese, engine, 
supplied wrth a high t^ech. low |ations . Cargo 

to meet tough em.ss.on con ro^ g ^ ^ 

capacity is two tons and - seats two P P ^ 
allows one to walk m the "Pj" ^ door 

cabin to the cargo area, and ear and \u» 9 
can be conveniently opened from '™J e ^ ss and 
accordance with the concept E «^ e featUfes 
Safety". Toyota and YTC ad d « f^raLportation 
every year. the 
regulation are ve ^ ^^f.'k Every truck must 
freedom on how to build the t uck- J The 
pass a very stringent annua, nspectio^ 
inspections add to the difficulty r tc m 

trucks. Naturally P«°P* from Transportation 
been struggling with automate b the 

agencies since the very beginning. Fmcouk ^ 
American UPS truck, relying on piwu . 

more 

improv ed the no match 

restrictive regulation, the Ta *^"° the dre am to 
to te UPS counterpart. J£«££?£ a**, runs 
make a perfect truck wh eh P^esm ^ 
without polluting the environment, and 
government regulation, is still alive. mental)y 
YTC also explores th » use of e {j| 

sound lu.1.. P^f" 0 ' ^"foped with othe. 
powered cars are being deveiope 

companies. . rlllHp 300O rosenbir 

YTC's 21.200 " C ^" hSesofwhicr 

trucks and I was profoundly impressed 
excellence. 
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Takkyubin Truck 

Figure 8 

(Walk Through Truck) manufactured by Toyota. 

SPECIFICATIONS 1991 MODEL (TOYOTA MOTOR 
CORPORATION) 



01MENSI0NS (M) 


LENGTH 5.02 WIDTH 1.79 HEIGHT 2.9 


CLEARANCE 


0.85 H 


CARGO AREA (H) 


LENGTH 2.80 WIDTH 1.60 HEIGHT 1.74 


CAPACITY WT . 


2 TONS 


CAPACITY VOL 


7.79 CUB. M 


ENGINE 


2.977 CCM 


WHEELBASE 


2.50 H 


TURNING RADIUS 


4.60 M 


TIRES 


FRONT 195-14-6 REAR 185-14-8 
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IV.. DTD INFORMATION SYSTEM 

"Kuroneko Yamato Takkyubin* is the name of our 
door to door delivery service. It operates from 8 a.m. 
to 8 p.m., 365 days of the year. The popular saying 
■Call Yamato for a pickup today, to deliver tomorrow", 
is used all over Japan to request Takkyubin service. 
We provide next day delivery to 99% of Japan. This 
service is controlled by a state of the art computer 
network. 

Every driver has a handheld computer (POS). 
Several phases of the parcel delivery are entered into 
the POS: the pickup, the arrival at the originating hub, 
the completion of sorting at the destination hub and 
the final delivery. This allows YTC to locate any parcel. 

Information is entered by the driver with his 
portable POS and is transmitted by a tele- 
communication network. Passing through the YTC 
sales offlces's WS (work station) to the hub's mini 
computers, the data feeds into the mainframe 
computers in Tokyo and Osaka. 

The database in the mainframes are updated 
every 15 minutes. Parcel tracking for customer service 
is possible from 8 a.m. to 10 p.m. YTC calls this 
•Parcel Inquiry Service." The parcel's ID number, which 
is supplied on the invoice as an bar code, allows 
instant parcel tracking. 



Parcel Inquiry Screen 



Trtctiitf-No Status 

£3 S v SJS n.« nggo -«o« jog 

Arr. K«» 07/ 17 JO-00 05;25 K2Z080 0M«T 



1992/07/li U:4J:0« * 



SCIEEl 



Off. *mv. C»fit.l»0. fli 9 nt Ewiloyct Header 
0«t« Code Co** T««e let -no -«o **> -Re 



i 20 StJtwi 



POO 07/15 JO- 19 

Tim TOO M/lfl M-I9 



09:46 



04 42 85 
0442&S 



szaa«4 



J21M1 
321301 



Figure 9 

Any of YTC's truck drivers or 1,600 offices offer 
the customer instant parcel tracking. Customer service 

is at its best. , . , 

Yamato System Development (YSD), to which I 
belong, is YTC Group's pivot computer company which 
handles ail YTC Group's communication networks and 
information systems. YSD has Fujitsu and IBM main 
frame computers. These powerful computers are 
located in Tokyo and Osaka and are the backbone for 
database management and information communication 
networks. In case of an emergency, Tokyo and Osaka 
centers mutually maintain real-time backups. 24 hours, 



it Ua4 Trwaportalioo Sntea by Box Palelte Container 




Urn 3ick teport 



port j 



Parcel Inquiries 
toforutioo 



NEKO' ON-L INE SYSTEM 
Parcel Tr.ckio, Statu, Datable of KURONEKO Ttlkfrtjj^ 

Service Level Check Sratw of TakkTubin Information 

V . ' 





Parcel Unusual 


/ 


Intonation 



Figure 10 
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Figure 12 
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365 days per year. Main networks have relay points all 
ever Japan, using double NTT (Nippon Telegraph and 
Telephone) and NCC (New Common Carrier) high- 
speed digital circuits. Each line has at least one 
backup line. Every relay point, is connected with over 
1,600 centers, total communication line length is more 
than 242,000 kilometers (151. 000- miles). 

In 1982 YSD's Value Added Network (VAN) 
service was the first to be certified by the Ministry of 
International Trade and Industry for public use. Today 
the system supports YTC and over 180 customers with 
over 13,000 terminals. In 1990. YSO installed a 
International Leased Une (High-speed digital circuit) 
from Tokyo to Los Angeles to start overseas network 
services. 

Recently. Matsushita (Panasonic) asked YSD to 
operate Electronic Data Interchange (EDI), so the trend 
is from VAN to EDI. 

Today. Yamato System Development is 19 years 
old has a capital of 1.8 billion yen, and 1,100 
employees. YSD also provides services outside of 
YTC. In 1991 65% of all sales income, which was 18.8 
billion yen, was generated from outside customers. 



Profits were a sound 1.1 billion yen. We have over 700 
system engineers in our development department. 
YSD has its own delivery business. Our eight 
distribution centers (warehouses), approved by The 
Ministry of Transport, have total area of 23.1 square 
kilometers (9.0 square miles). Approximately 30 trucks 
support the Distribution Operation Centers. 




Figure 14 




Figure 13 
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YSD SYSTEMS 



1. Transportation Information Systems 

1 MCA Delivery Support Systems 

- Pickup Control System - Dispatch Management 

- Delivery Control System - Under Development 

- Driver Control System 

2 Hub Control Systems 

• Automated Sorting System 

- Unit Load System 

3 Digital Driving Pattern Monitors 

* Report Generator 

- Speed. Idle, Rpm, Weight tracking 

- Fleet Management System 

2. Delivery Monitoring Systems 

1 Delivery Status Monitoring System 

2 Delivery Volume Monitoring System 

3. Customer Information Systems 

1 Pre-Print Invoice System (Volume Customer) 

2 Customer Information System 

3 YSD Customized Systems by Business Types 

- Database Package for Home Business 

- Database Package for Mail Order Business 

- Charges Collect Support System 

4. Special Takkyubin Systems 

1 Cool Takkyubin Support System 

2 Book Takkyubin Support System 

3 Food Takkyubin Support System 

4 Time Takkyubin Support System 

5 Leisure Takkyubin Support System 
(Ski. Gotf. Luggage) 

5. Application Software 

1 Accounting Packages 

2 Personal Resources Management Systems 

3 Business Management Systems 




Figure 16 




Figure 15 
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V. TftUCK INFORMATION SYSTEMS 

Below are some examples of YTC's Information 
technology in relation with Takkyubin trucks. 



way 



1. PICKUP WITH MCA 

Mutti Channel Access (MCA) is a two 
communication radio system. 

Yamato has 260.000 agenc.es throughout Japan. 
Parcels can be dropped off at any YTC office or 
agency. Takkyubin trucks provide scheduled pickups 
8 their agencies. Parcel drop offs are discounted at 
Too yen per parcel. In urban areas YTC must parte 
superior pickup response tor larger parcel volume in 
Sr to compete' with other delrvery serv.ce* 
Sdcyubin pickup requests by telephone are 
immediately transferred to the truck nearest the 
Corner. Yamato doesn't want customers :* wJL 
•No wait pickup- is the bas.c goal to beat he 
competition "and this can only be ach.eved wrth the 
help of computer information systems. 

Before we had integrated network support the 
basic Pickup procedure was as described below. A 
Corner caHe'd and the operator had to wrrte the 
name address, parcel quantity. t.me. etc. on a 
memorandum. After receiving several pickup orders 
I operator sorted them, and called the trucks ; ctoses 
to pickup area. This system worked fine but wrth 
growing parcel volume problems occurred The 
foLings were the major problems we encountered. 



(D 



(2) 



(3) 



Errors happened because extensive customer 
SSmatior . had to be written down for each new 

22 the busiest hours of 4 to 6 p.nv 
operators had to put customer on hohl MCA 
communications were also °vertoaded . » many 
operators couldn't get in touch wrth the truck 
drivers which caused delays in pickups 
YTC safety regulations required drrvers to pull over 
to write down the operators mformafon. Very 
inefficient. 

To solve these three problems Yamato had 
developed a computer system to perform the following. 

(1) Customers telephone number and addresses are 
1 } stored in databases. When a customer calls the 

telephone number has to be entered, and 
customer information is dispfcyed on the screen rf 
fhe work station. The operator now enters orrry 
S^S^nd the number of parcels, reducing 
the time of telephone conversat.cn wrth the 
customer dramatically. 

(2) The system uses the truck database to find the 
truck closest to the pickup location and MCA 
transmits the information to the truck^ 

(3) Each truck is equipped wrth an on board 



computer and can receive the p.ckup orde ^The 
up-to-date information can be yiewed on a Uqu.d 
Osplay Screen (LCD) screen or printed ouL 
Ml After pickup the driver enters the confirmation 
( } whfch * transmitted the YTC. allowing customer 
parcel tracking and Automatic Vehicle Monrtonng 

m Mm vellow pages on disks, make it easy to 
® 52, Lin updated'customer databases eliminating 
entry errors. 



Pickup Order System 



HCA Radio 
mOTOROLA) 



9 




_ -rUS. tit & 
P;sl-Uf Order Enirr Ter»;«^ 




Figure 18 
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MCA SYSTEM SPECIFICATIONS 
BASE STATION 

(1) Motorola (800MHz) MCA SYSTEM 

(2) Fujitsu minicomputer 

(3) Fujitsu FMR personal computers 

(4) Telephone operator Work stations (WS) 16 max. 

(5) UNIX operating system and IAN 

(6) One Fujitsu minicomputer connects with three 
Motorola MCA. 

SYSTEM CAPACITY 

(1) 1 ,000 Takkyubin trucks 

(2) 20,000 customers (Upgrade to 200,000) 

(3) 10,000 pickups a day 

(4) Advanced pickup scheduling, 10 per customer, 
1,000 a day. up to 3 months advanced notice 

(5) 10,000 district names to simplify address entry 
(Upgrade to 200,000) 

(6) Reports: Operator performance, MCA usage etc. 

YTC added the MCA radio communication 
system and the customer databases to improve pickup 
service. The system combined with our drivers mission 
to serve the customer best, gives YTC a leading edge 
over the competition. 

Base stations are in every major city and business 
areas. Each base station is surrounded by order 
stations (telephone operation centers). These stations 
support over 9,000 Takkyubin trucks. 

2. ROSENBIN CONTROL SYSTEM 

Parcels are collected by Takkyubin trucks and 
transported to the local hub. From there YTC's 



rosenbin trucks transport the parcels to' the destinatio 
hub. The Rosenbin Control^ System supports, th 
process. 

Every hub has a schedule board similar to th 
departure and arrival boards in airports. This boac 
informs drivers and other employees to facilitate the 

work. . 

The number of hubs has steadily increase 
reaching 64, in August 1992. Rosenbin trucks ha\ 
about 2,000 scheduled routes per day (See figure 
During the holiday season additional support routes a 
added, totaling over 6.000 a day. 

YTC's supervisor used to write standard scheduh 
for every route. Changes in parcel volume and truck - 
driver availability forced the rewriting of the schedule 
The schedules were then handed to the truck drivers. 

Today the supervisor obtains his schedules from 
PC. He only enters the driver's name and tru< 
number. The truck driver enters the number 
containers and additional cargo information. All data 
transferred to update the databases and the Rosent 
Control System's mainframe. 

The above pre-alert information is used by tt 
destination hub to prepare for arriving truck shipment 

Every truck sends a constant identification sign; 
which is received by electronic check points along tl 
roads. The truck location is then transmitted to ti 
system. In addition the system allows voi- 
communication between trucks and hubs. 

The purpose of this system 

(1) Advise truck driver of traffic jams, accidents ai 
give alternate routes 

(2) Provide anticipated delivery time for customer 

(3) Give pre-alert information to destination hub 




The information provided includes 



ROSENBIN SYSTEM SPECIFICATIONS 



Destination and arrival time T .,^'« 
AVM (Automatic Vehicle Monitoring. Trucks 
location) 

Traffic jams, accidents etc. 

floseno/n truck schedule status (delays, problems) 
Latest road and weather reports 



(D 
(2) 

(3) 
(«) 

(5) 

. YTC obtained the Ministry of Posts and 
Telecommunication's approval to use two radio 
frequencies throughout Japan, to develop his system. 
Sroved frequencies are 382.775 Mhz for truck o 
£?. communications and 398.775 Mta for base to 
Suck communications. In September 199 a 
Soanese consortium started a project to use a satellite 
£Sc control. The first satellite based 
ZJ£L£^ wil. be in operation in spnng 

1993 YTC has planes to use the satellite network in the 
future The system will be able give the exact truck 
oositfon anytime, anywhere. We plan to .mplement a 
Astern to use GPS (Global Positioning System) 
which is managed by the Pentagon. 




denote Controller 



r 



CD 



RADIO BASE 
a MIC 




Call Units 



Voice 
File 



Controner(Cnl) 




(D 
(2) 



(3) 



(4) 
(5) 



(6) 
(7) 



Frequency Band 400 MHz / 
Communication Method 
. Dual frequency 

- Semi-duplex operation 
Transmission Power 

- Base 10W 
-Truck 10W 

1 ,000 trucks capacity 
Transmission activation 

Consecutive for base 

On demand for truck 
Baud rate is 1,200 bps 
Modulator Method 
MSK 1,200 Hz* 100 
Space Frequency band 1.800 - 100 



3. DIGITAL DRIVING PATTERN MONITORS 

guidelines, Recently they have been 

This units with speedometer, odometer, and weigni 

SSttSfS gu«.e«nes and «np— ** 

"^SSS^ « no. 

rest of the information system. The mw *9«" 
lechnology allowed integration of the two systems. 

Advantages of a digital monitors 

(1) All recorded data is feed into the network 

(2) Improved accuracy for driving patterns 

(3) Assists driver 

To be able to start the truck, the driver must insert 
his own IC memory card into the d.g Th. 

reC orded information t^J^VSST* < he 
pns everv 0.5 seconds. This aaia » ^ ofotu 
NEKO network. YTC benefits from ^ 
more efficient scheduling and the capatatty to analyze 
overall fleet performance. 

Information from digital monitors are 



0) 
(2) 
(3) 



Driver name, departure and arrival times 
Fuel and oil consumption 
Operation hours, distance travelled, rest 
speed, length of stops, etc. 



time. 



Figure 20 
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DIGITAL TACHOGRAPHY SAFETY MANAGEMENT 



Beadourters (3*fclT to* ) 



# Priot Out lirvtsi Seporl 
of Acctdeal 
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Hos t 
Compu t e r 
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Initialize Xacfcloe 



• Preilbl Factory 
Set u iaitiat itc 
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□ 



JUL 



Portable 
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for aaalnc 
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& SafetT aaaxter- Prial o«t lae faniog 
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(Thei over the safe IT level) 




Oita noire 
, even 0.5 sec. M — ^..j 

s»s) m& 





s<icj orcicc 




•ora 

Static* 



x 



Priit eat Bosioess 8 e port 
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Of**** Ofheo transfer) 
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level) 
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Figure 21 



VI. TAKKYUBIN TRUCKS FUTURE 

Door to door parcel service is now a stable 
business monopolized by the big three. But there are 
many improvements needed. A serious problem is 
Japan's acute shortage of human resources. Our 
drivers can deliver an average of a 150 parcels per 
day. YTC has a hard time to hire enough drivers to 
keep up with the constantly increasing parcel volume. 
To ease the driver crunch we reduced their working 
hours, but we still have a shortage. For DTD the driver 
is the core and can not be replaced by any technology. 
Faced with these problems we try increase our 
productivity to perfection. Logistic management 
constantly tries to reduce empty cargo space, 
streamline pickups and reduce redeliveries to a 
minimum. Cost reduction, service improvement, and 



speedier delivery are the driving forces. We ha 
found the almighty strategy, superior inform 
systems to support the drivers are needed. 

Individual hardware and software is getting \ 
powerful. However, integration of all our syst 
including communication networks and database 
necessary to meet future demands, i.e. a Inform 
But we can not afford to forget about the 
important aspect, safety. 

Japan's DTD service has come a long way s 
its start. With over 1.5 billion parcel delivered anm 
we are a strong and respected industry. To pre 
the best service to our customers, enabled 
success. We will strive to meet our custo; 
demands with total logistic management. 
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The Physical Distribution Information Network 
The Phyaou Delivery Business 

111 tu Takashi Sekita 

Director 

Applications Improvement Dept. 
Yamato Transport Co., Ltd. 

hare of Yamato Transport Co. is 40% and it 
Recently, information s ^ ^ ^ ta „ oligopolistic situation together with 

mad e remarkab* prog** ^ ond «JL Pelican (Nippon Expr«s 

business. It can be sa>d that the POS sywm. ^ ^ ^ ^ m ^ charaC . 

which reflects the downstream era is a typtcal ^ Co . is 

case. Also, in the physical distnbuuonbus, ^c 

ness. information is captured at its source n ts dtrect g ^ ^ ^ ^ 
*e procurement, manufacturing sa es^and w its * oroug hgoing 

consumption stages, and progress ,s being m 
made through improvements » .honwghg* ^ u putting van- 

ing customer services, in quahty control m MWW I ^ ^ "Home-Delivery Serv- 
improvement of work efficiency « develop- £ ne ^ ^ ^ 

mem of new systems and in *e devetopmcnt » ' nome . d elivery serv- 

of new businesses. In any case, these thmgs uch ^ home . oelivery service, 
do not stop with at the improvement of the ef- • ho me-delivery service, 

ficiency of an individual business, and a, c«h o ^ ail . 

seen in logistic physical distnbuuon. they «*■ delivery service, in adcfc- 

„ total sales strategy by the ****** ^l^neral-icems nondelivery serv- 
utouon of information. This shows the ,m- uon to tt, ^ ^ ^ ^ Qf ^ ^ 
portance of networks. I hope I can help you* ^ ^ of ^ 

^tand the relationship between physc* ^ „ * dcUvere d on the 

distribution and information by mtroductng The perce g ^ ^ ^ 
oar company's "home-delivery-service mfor- next cay 
mation network system" in .his arucle. 



1. General Situation of the Home- 
Delivery Service 

Yamato Transport Co. has 40.000 employees. 
U00 offices and 20.000 vehicles. It handles 
one million home-delivery items a day and 
400 million items a year. Since the total 
number of items handled by the endre home- 
delivery business is 1 billion items, the market 



Positioning or tbe Information Net- 
wort System 

A selling point of this home^livery service 
is its system. The system can be explained 
using the human body. Offices are developed 
(skeleton) along with the sales strategy 
(brain), loading and unloading (muscle) ac- 
tivities are performed on the basis of the of- 
fices, and the system of these muscles and 

^ tor Onflrterlv 



-^o / 0*40000 = 0. L.- b/ar/\ 



bones is controlled by information (nerves). 
The home-delivery service cannot be carried 
out without an information network system. 



This information can be divided into "up" 
information and "down" information. The 
sources of the "up" information are the items 
to be delivered. The important thing is how 
quickly the item information (slip number, 
customer name, type of item, transport sec- 
tion, fart, etc.) can be obtained. This is the 
origin of the POS concept On the other hand, 
the "down" information is feedback of the 
obtained information, and means the utiliza- 
tion of information in a way thai contributes to 
customer services, quality control and im- 
provement of efficiency. The "down" infor- 
mation does not exist without the "up" infor- 
mation and the "up" information does not 
exist on the assumption of the existence of the 
-down" information. The thing to connect the 
"up" and "down" information is the database. 
The information network is the general term 
for this. 

3. "Up" Information (Collection of 
Package Information) 



delivery is completed (including the bringing 
back of goods), or when abnormal packages 
are found (misdelivery, unknown address, 
breakage, e*.). In such cases. SDs need do 
nothing but scan a slip number (bar code). All 
of the data is transmitted to the host computer 
in Tokyo. 



POS (Point Of Sales) in the transport field 
means the point of receiving packages. Pack- 
age information taken at this point can- con- 
tribute to quality control and customer serv- 
ices. Therefore, our company gives all the 
sales drivers (SDs) a portable terminal so that 
they can input data. Of course, the primary 
role of SDs is the collection and delivery of 
goods, but they contribute to the management 
of the company by reflecting the viewpoint of 
the customers in their area. This means man- 
agement by all members. SDs are not merely 
doing blind work. They input data when 
packages are taken out for delivery, when the 



4. Information Network (NEKO Net) 

The following is the route of information 
transmission. The data collected by the above 
mentioned SDs is stored in their portable ter- 
minals. This portable terminal is called a PP 
(Portable POS) in our company. The terminal 
is connected (jacked in) to a WS (workstation) 
in the office when the SD goes out to make a 
delivery, or when he returns to the office after 
the collection of goods. Then the data is 
transmitted to a small computer (cluster) in- 
stalled at a key base (usually one place m each 
prefecture) that manages the office, through a 
public line. The data is automatically trans- 
mitted from the cluster to the host computer in 
Tokyo through a leased line (optical cable): 
that is. all the data is stored in a database of the 
host computer. Then, it is processed accord- 
ing to its purposes, changed into "down" in- 
formation (applicable information) and then 
distributed to die necessary locations (See 
Figure 1 & 2). 



5. Database 

The host computer that takes charge of the 
database is located in Kamiuma. Tokyo. It is 
controlled and operated by the Yamato Sys- 
tems Development Co. This is a 100% in- 
vested subsidiary of the Yamato Transport 
Co which was created through making the 
computer section of the Yamato Transport 
Co independent in 1972. Since then, the 
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Yamato Systems Development Co. has under- 
taken not only the important mission of infor- 
mation processing for the Yamato Transport 
Co., it has also responded widely to the de- 
mands of other companies. The data on vari- 
ous goods that is stored in the databases is 
processed according to its use and purpose. 
The company computer is used for on-line op- 
erations from 8:00 am. to 10:30 p.m. and for 
batch processing (fare receivables and related 
billing work, wage calculations, flash reports 
of sales and various statistical operations) 
during the night shift However, as for the 
pursuit of goods," which is described later, 
batch update is performed at 30-mtnut£ inter- 
vals in the daytime also for real-time informa- 
tion. By taking the cable fire accident that oc- 
curred in Setagaya in 1984 as a lesson, a 
backup host machine is installed in Osaka. 

6. 'Down" Information (Utilization of 
Information) 

Although there are various information us- 
ages, two typical examples will be introduced 
here. 

(1) Package Tracking System 

What is happening to his or her package is the 
customer's greatest concern. Therefore, re- 
plying to this concern is the duty of the trans- 
porter. As described in the section on "up" in- 
formation, package information is stored in 
the host computer, therefore, it can be seen 
immediately when and from where the pack- 
age was sent and what is happening to it now, 
including the delivery process. Although it is 
not easy to search for a certain package from 
a great amount of data, the current computer 
can do it without difficulty. 



(2) Checking Service Level (Control or 
the number of transport days) 

What attracts people to the home delivery 
service is that delivery is made on the next 
day. Breaking a promise is an important issue. 
To check this, each delivered item is watched 
with the computer to see where it was sent 
from, where it was transported to and in how 
many days, regardless of whether or not a 
complaint was made. The percentage of unde- 
livered items (the percentage of the number of 
items exceeding the specified number of days 
for transport) is calculated for the territories 
with bad delivery performance. The levels of 
performance ait distinguished by color, such 
as red and yellow, as an index to improve the 
quality of transportation. This is outpuued 
once a month for an ordinary month and out- 
puued every day in December, which is a busy 
month. 

7. Radio System Using the Computer 

There are two radio systems thai connect ve- 
hicles and offices. One is a collection instruc- 
tion system for collection vehicles and the 
other is an operations control information sys- 
tem for operations vehicles. 

(1) Collection instruction system 

The requests from customers for collection of 
items are made by telephone to an office. The 
reception clerk asks for the customer tele- 
phone number and inputs it into the reception 
machine, then data such as customer name, 
address, and telephone number is displayed 
on the screen. This data is automatically 
transmitted to the appropriate vehicle by wire- 
Jess and is primed on a printer on the driver's 
seat Consequently, collection activity can be 
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performed immediately by this system, ena- 
bling just-in-ume response to a customers' re- 
quest. 

(2) Operations control information 
system 

This is a tracking system for the operations ve- 
hicles that mainly travel for long distances at 
night Check points (offices) are established 
along trunk expressways. A special radio- 
wave network is spread over these areas to 
automatically catch the operations vehicles of 
the company that pass through. This data is 
automatically reported to the host computer 
and the host computer collates the data with 
the schedule. If there is a delayed vehicle, the 
host computer reports this to the destination 
office so that the work setup can be pread- 
justed (See Figure 3). 

g. New Businesses 



The home delivery service network is in- 
volved in the creation of new businesses. 
Recently, direct marketing sales without a 
store, such as direct sales from areas of pro- 
duction and mail order sales are being devel- 
oped, but they cannot be carried out without 
home delivery service as a consumer-diiect- 
connection-type system. Therefore, we are 
creating subsidiaries that will provide assis- 
tance services related to customers sales and 
collection of money and information as a 
regular part of business, not as a side business 
to the home delivery service. 

(1) Yamato Collect Service Co., Ltd. 

This is a 100% invested subsidiary of the 
Yamato Transport Co. This company is in 
charge of the cash -on-deli very business of 



home delivery. The payment for goods can be 
collected quickly without errors by append- 
ing the price of the goods to the home delivery 
slip Although it was performed by the major 
transport companies who called it "cash-on- 
delivery." as it was very troublesome, most of 
die companies tried to avoid it. However, 
with the spreading of the informauon network 
together with the improvement of home deliv- 
ery service, it can now be performed securely, 
quickly and easily. This business is changing 
with good results. 

(2) Yamato Systems Development Co., 
Ltd. 

This company is a 100% invested subsidiary 
of- the Yamato Transport Co.. and manages 
their NEKO system, mentioned above. 
Yamato Systems Development also provides 
computer services to other companies and 
these sales are greater than sales to Yamato 
Transport. This is the first VAN company m 
japan and it supports various sales systems, 
named Joints, such as telemarketing. POS 
system, collection of payments and agent 
salesman control. The customers need only 
endeavor to use these systems for merchan- 
dise planning and advertisement. The packet 
switching network is overlapped on the 
NEKO Net with access points provided 
throughout the country. This system is sold as 
an assistant (connected with home delivery) 
VAN awaiting customers' use (See Figure 4). 



(3) Book Service Co., Ltd. 

This is a joint-investment company with 
Kurita Bookstore for the sales of publica- 
tions, the procurement of ordered publica- 
tions and their delivery throughout the coun- 
try. As a publications database is available. 



orders made by postcard, telephone, facsimile 
machine and personal computer can be proc- 
essed through their offices all over the coun- 
try, and then the ordered publications are as- 
sembled and delivered. The collecting system 
of Yamato Collect Service is used for the col- 
lection of money. The cost for delivery of a 
standard-sized box is 300 yen throughout the 
country. 



9. Conclusion 

We are in a global age. Even if it is night 
where you live, somewhere on the earth it is 
day. Japan can keep an all-night vigil. Devel- 
oping an uninterrupted global computer net- 
wort: will be even more desirable in the fu- 
ture. 
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METHOD AND SYSTEM FOR CONDUCTING 
ELECTRONIC COMMERCE TRANSACTIONS 

Cross-Reference to Related Application 
This application is a continuation-in-part of U.S. Provisional Application No. 
60/054,121, filed July 29, 1997. 

Background 

fif| n of thf Invention 

This invention pertains in general to electronic commerce and in particular to a method 
and system for conducting electronic payment transactions via the Internet. 

RArKf.ROlIN" nr THF INVENTION 

Electronic commerce conducted over the Internet has become increasingly important 
over the last decade. Online merchants offer goods and services for sale or rent including 
physical objects such as compact disks, books, and clothing, and intellectual property such as 
streaming music and movies and electronic books. Physical items may be delivered to the 
customer via the mail or a variety of other shipping options. Intellectual property, in contrast, 
may be delivered to the customer by allowing a download via the file transfer protocol 
("FTP"), providing the customer with an access key, establishing a telnet session, or through 
some other form of electronic delivery. 

Typically, these goods and services are displayed on the merchant's web site and a 
prospective customer views, selects, and purchases the goods using web browsing software 
such as NETSCAPE NAVIGATOR*. The customer usually pays for a product by establishing 
a secure connection with the merchant's web server and transmitting payment information, 
such as a credit card number, to the merchant. The merchant then uses back-end processmg to 
verify the payment information and receive payment. For example, the merchant may use a 
secure telephone line or network link to contact the credit card issuer before accepting the 
customer's order. Eventually, the merchant and credit card issuer settle payment and the 
merchant delivers the product or service to the customer. 

A difficulty with the above-described scenario is that each merchant must implement an 
inventory and payment database and a payment acceptance and verification system. For 
example, the merchant must establish and maintain a database tracking sales, delivery, and 
payment information and product inventories in order to support the electronic commerce 
system There is sienificant cost and complexity in maintaining this database, including the 
difficulty of integrating it with legacy accounting and fulfillment systems and aggravated by 
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the scarcity of truly skilled personnel. In addition, the merchant must design web pages to 
securely accept the order and payment information and implement the functionality to verify * 
the payment. These tasks can be extremely difficult if the merchant accepts payment using 
many different methods, such as credit cards and electronic fund transfers, or accepts payment 

5 in more than one currency. Moreover, having a large number of separate payment acceptance 
systems on the Internet provides a greater opportunity for fraud and abuse because the flaws of 
each system can be exploited. 

Although Internet-based electronic commerce clearinghouses have been developed to 
handle transactions from many different parties, these clearinghouses do not provide a 

10 convenient interface to the merchant. In addition, the merchant must still establish the 
payment, verification, and database systems described above. 

Accordingly, there is a need in the art for a method and system for conducting 
electronic commerce on the Internet which reduces the amount of work that must be performed 
by the online merchant. Preferably, the method and system will allow the merchant to easily 

15 and verifiably perform inventory, sales, and delivery tracking and transparently support 
different types of payments and currencies. 

Summary of the Invention 

The above needs are met by a method and system for conducting electronic commerce 
20 transactions that allows a merchant to easily sell a mix of physical and intangible items and 

supports sales, inventory, and delivery tracking and a variety of payment systems by having the 
merchant establish an account on a commerce server. The commerce server provides the 
merchant with inventory, accounting, and order management systems. Furthermore, the 
commerce server allows merchants to conduct electronic commerce with other merchants and 
25 vendors. 

The commerce server includes a web server providing web pages to the merchant. By 
using these web pages, the merchant establishes an account on the commerce server. Then, the 
merchant provides the commerce server with information about an item sold by the merchant, 
such as a plane ticket, clothing, a book, a software product, or playing time with an online 
30 game. The merchant also provides the commerce server with other attributes of the item from 
which the customer may select, for example, the quantity or duration of an item. In addition, 
the merchant supplies payment processing rules defining the payment options that are 
acceptable to the merchant, such as which currencies and payment systems are allowed and 
when or how often to bill the customer. 
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The conferee server preferably stores the information received from the merchant in 
an entry of a database. In one embodiment, the database entry categorizes the item as a hard < 
good soft good, or online good depending upon the delivery options available for the item. 
The commerce server, in addition, provides the merchant with a "payment button" includmg a 
universal resource locator ("URL") that points to the commerce server and includes 
information allowing the commerce server to identify the database entry with which the 
payment button is associated. The merchant preferably publishes the payment button on the 

merchant's web site. 

The customer selects the payment button when the customer wishes to purchase the 
3 assorted product. In response, the customer's computer is automatically directed to the web 
server managed by the commerce server and provided with the item information entered by the 
merchant In addition, the customer is presented with the payment options allowed by the 
merchant's payment processing rules. Preferably, the customer then provides the web server 
with the payment information necessary to complete the transaction. 
5 When the merchant's payment terms specify that payment is required, the commerce 

server preferably identifies the remote payment system selected by the customer and contacts it 
to complete the electronic commerce transaction. Preferably, a module within the commerce 
server converts calls generated by the commerce server into the format used by the selected 
payment system. Likewise, the module converts responses received from the payment system 
20 into the format used by the commerce serve, Then, the commerce server notifies the customer 
and the merchant of the result of the electronic commerce transaction and, if appropriate, 
delivers the item using one of the delivery options specified in the database. 

A method of conducting electronic commerce between a remote customer and a remote 
merchant in accordance with the present invention includes receiving information identifying 
25 an item to be purchased by the customer, receiving payment information specifying a payment 
method to be used by the customer to purchase the item, conducting a payment transact.cn 
with a remote payment system specified by the payment information, and providing the 
customer and the merchant with the result of the payment transaction. 

Similarly, computer program instructions for conducting electronic commerce 
30 transactions in accordance with the present invention include instructions for storing item 
information received from the merchant, instructions for issuing the merchant a reference to 
the stored item information, instructions for receiving an electronic commerce transaction 
identifier from the customer containing the reference to the stored item information issued to 
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the merchant, instructions for acceptingpayment information from the customer, and 
instructions for conducting the electronic commerce transaction with a remote payment system. 

Brief Description of the Drawings 
5 FIGURE 1 is a high-level block diagram of an electronic commerce system according 

to an embodiment of the present invention; 

FIGURE 2 is a high-level block diagram illustrating functional components of a 
commerce server according to an embodiment of the present invention; 

FIGURE 3 is a high-level block diagram of an entry in a database associated with the 
10 commerce server according to an embodiment of the present invention; 

FIGURE 4 is a flow diagram illustrating the interactions between the customer, 
merchant, commerce server, and payment system when completing a payment transaction 
according to an embodiment of the present invention; and 

FIGURE 5 illustrates an exemplary screen display of a web page seeking payment 
15 information from a customer; and 

FIGURE 6 illustrates an exemplary screen display of an order confirmation web page. 

Detailed Description of the Preferred Embodiment 

As used herein, the "Internet" refers to the global network of interconnected computer 
20 systems and the "World Wide Web" ("WWW") refers to the global hypertext system using the 
Internet as its transport mechanism. A "universal resource locator" ("URL") is a reference to a 
piece of information or a software function on a computer connected to the Internet. A "web 
server" is a program that accepts requests for information framed according to the HyperText 
Transport Protocol ("HTTP"). "Web pages" are the information supplied by the web server in 
25 response to the requests. The Common Gateway Interface ("CGI") is the standard that 

describes how the web server accesses external programs, usually called "CGI programs" or 
"CGI scripts," called by a web page. Of course, the present invention is not limited to the 
Internet and may be used with any digital network supporting electronic commerce. In a non- 
Internet-based system, the terms defined above also include the non-Intemet-based equivalents 
30 for communicating between the various entities described herein. 

FIG. 1 is a high-level block diagram of an electronic commerce system 100 according 
to an embodiment of the present invention. Illustrated are a customer computer (sometimes 
referred to as "the customer") 1 10, a merchant web server (sometimes referred to as "the 
merchant") 1 12, and a commerce server ("CS") 114, all coupled to the Internet 116. In a 

4 
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typical embodiment, the customer computer 1 1 0 is a personal computer having, among other 
things, a processor, memory, storage device, and monitor. The customer computer 1 10 is 
coupled to the Internet 1 16 via a network connection 118. The network connection may be, for 
example, a modem coupled to an analog telephone line, a digital subscriber line, a cable 
modem utilizing bandwidth on a cable television coaxial cable, a high speed digital line, or any 
other communications medium. Web browsing software, such as NETSCAPE 
NAVIGATOR*, preferably executes on the client computer and sends data from the client 
computer 1 10 to the merchant web server 1 12 via the network connection 1 18 and Internet 
1 16. In another embodiment, the customer computer 1 10 is apalm-top device or personal 
digital system communicating via radio waves with the Internet 1 1 6 or another electronic 
commerce system. 

The merchant web server 1 12 is preferably similar to the customer computer 110 except 
that it is has the processing power and communications 1 1 6 bandwidth to handle multiple 
simultaneous customer transactions. The merchant 1 12 sells items, such as merchandise, 
information, intellectual property, and/or services via a web site hosted on the merchant web 
server 1 12. The merchant's 1 12 web site may, for example, display a catalog of software 
available 'for purchase, allow the customer 1 1 0 to view flight schedules and purchase a plane 
ticket, or allow the customer 1 10 to play an online game, download a book or music, or access 

a database of information. 

As used herein, the terms "customer" and "merchant" depend upon the specific 
transaction being conducted. In a chain of commerce transactions, the "customer" in a first 
transaction may be a "merchant" in a second transaction. For example, the customer 1 10 may 
buy components of a product from several different vendors or merchants 1 12 using the 
electronic commerce system described herein and then, in turn, sell the combined product via 
the customer's own web site and the CS 1 14. 

The merchant's web site displays at least one "payment button." A payment button is a 
graphic button, a region of a larger graphic, a text string, or another form of URL link which 
the customer 1 10 may "press" by selecting it with a mouse, physical button, or other input 
device, in another embodiment, the payment button may be utilized on a non-Internet-based 
electronic commerce system. In such an embodiment, the payment button is considered to be 
"pressed" whenever a customer 1 10 expresses a desire to purchase an item. As described 
below, the payment button is pressed by the customer 1 10 when the customer 1 10 wishes to 
purchase and pay for an item displayed for sale on the merchant's web site. In a preferred 
embodiment, every type of item for sale on the merchant's web site has a separate payment 
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button. When a customer 1 10 wishes to purchase the product, the 1 10 customer presses the 
product's associated payment button. Then, the customer 1 10 is preferably presented with a ' 
menu allowing the customer 1 10 to specify attributes, such as quantity or duration, of the items 
that the customer 110 wishes to purchase. 
5 In another embodiment, the merchant web site has only one payment button or has only 

one payment button for each class of items for sale. In this embodiment, the customer 1 10 is 
preferably presented with a menu of choices after pressing the payment button. For example, 
the menu of choices may ask the customer 1 1 0 to identify a specific product or an attribute of a 
product, like colon that the customer 1 1 0 wishes to purchase. 
1 0 Every payment button has an associated URL that points to information in the CS 1 14. 

Preferably, a database key that uniquely identifies the merchant 1 12 and/or item for sale is 
encoded within the URL. When the customer 1 1 0 presses the payment button, the customer 
1 10 is redirected to a web page provided by the CS 1 14 and specific to the merchant 112 
and/or item. 

1 5 In one embodiment, the CS 1 1 4 queries the customer for the quantity or duration of the 

item that the customer 1 10 wishes to purchase and payment information. The CS 1 14 receives 
the customer's responses and conducts the electronic commerce transaction according to 
payment processing rules and delivery options specified by the merchant 1 12. The CS 1 14 
records the transaction in its database and notifies the customer and merchant whether the 

20 transaction was successful. Accordingly, the merchant 1 12 is relieved of the responsibility of 
conducting the electronic commerce transaction with the customer 1 10. 

FIG. 2 is a high-level block diagram illustrating functional components of the CS 1 14 
and also illustrating a remote payment system 222 and a remote merchant 223 according to a 
preferred embodiment of the present invention. The CS 1 14 is preferably similar to the 

25 customer 1 10 and merchant 1 12 computers, except that the CS 1 14 has enough processing 
power and Internet 1 16 bandwidth to support many simultaneous payment button transactions 
as described herein. The functionality of the CS 1 14 described herein may be performed by 
hardware or software modules within the CS 114. In one embodiment of the present invention, 
the functionality of the CS 1 14 is provided by software applications executing on INTEL x86- 

30 or SUN MICROSYSTEMS SPARC-compatible hardware under control of MICROSOFT 
WINDOWS NT or a derivative of the UNIX operating system, such as SOLARIS 2.5.1. In 
another embodiment of the present invention, the functionality of the CS 1 14 is provided by a 
distributed computing system as described below. 

6 
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The remote payment system 222 is preferably a third-party payment gateway or system. 
The gateway or system is preferably connected to a financial transaction network, which, in - 
turn, typically links to computers at banks and other financial institutions for approval and 
settlement of electronic commerce transactions. Typical gateways or systems may include 
5 CYBERCASH, e-CASH, MONDEX, or SET. While only one payment system 222 is 
illustrated in FIG. 2, the CS 1 14 may be in communication with many different remote 
payment systems 222, either through a secure link on the Internet 1 16 or a dedicated secure 
link. Each payment system has an applications programming interface ("API")- By using the 
API, the CS 1 14 communicates with the payment system 222 and performs secure and 
1 0 verifiable payment transactions. 

The remote merchant 223 is preferably a merchant selling items via a web site as 
described above. The remote merchant 223 may have an account on the CS 1 14 or the 
merchant 223 may have an interface for selling items similar to the remote payment system 
222. In general, the remote merchant 223 is included in FIG. 2 to illustrate that the customer's 
15 110 electronic commerce transaction performed by the CS 1 14 may contact a remote payment 
system 222 and/or a remote merchant 223. 

The CS 114 includes a payment button transaction engine 210 which is coupled to a 
database 212 and a web server 214. A firewall 216 preferably sits between the web server 216 
and the transaction engine 210. While these functional components are illustrated in FIG. 2 as 
20 discrete entities, the CS 1 1 4 may be executed on a distributed computer system having a 
plurality of engines, databases, and web servers working together the perform the functions 
descnbed herein. For example, one embodiment of the CS 1 1 4 uses multiple transaction 
engines 210 and web servers 214 and a single distributed database 212, thereby providing 
scalability to the CS 1 14. The number of web servers 214 and transaction engines 210 depends 
25 on the actual system load and the desire to achieve better performance through balancing the 
transaction load across the system. 

The payment button transaction engine 210 includes a rules module 218 that controls 
the interactions and flows of information necessary to complete a payment transaction. In 
addition, the transaction engine 210 preferably includes a Payment Application Programming 
30 Interface ("PAPI") module 220 enabling communication between the CS 1 14 and the remote 
payment systems 222 and merchants 223. The PAPI module 220 abstracts the different APIs 
of each payment system 222 and merchant 223 into a single, higher level, PAPI that can 
interface with each of the payment systems 222 and merchants 223. The transaction engine 
210 performs payment transactions with a payment system 222 or merchant 223 by making 

7 
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calls to the PAPI. The PAPI abstraction module 220 translates these calls into the specific API 
of the payment system 222 or merchant 223 being used for that transaction. The PAPI 
abstraction module 220 also translates data received from the payment system 222 or merchant 
223 into the format utilized by the transaction engine 210. Accordingly, the PAPI abstraction 
5 module 220 allows support for new payment systems 222 and merchants 223 to be added to the 
CS 1 14 by merely creating a new PAPI to payment system or merchant API mapping in the 
PAPI abstraction module 220. 

The payment button store module ("PB store") 224, in combination with the web server 
214, allows a merchant 1 12 to obtain a payment button. The web server 214 is preferably an 

1 0 industry standard web server such as the NETSCAPE ENTERPRISE SERVER or the 

APACHE web server. The web server 214 provides secure communication with the customer 
1 10 and preferably uses industry standard technologies including HyperText Markup Language 
("HTML"), and HTTP to deliver information to the customer 110. In addition, the web server 
preferably uses industry standard encryption techniques, including secure HTTP ("S-HTTP") 

1 5 and the secure sockets layer ("SSL"), to ensure that communications with the customer 1 1 0 are 
private. The firewall 216 allows only authorized communications between the web server 214 
and the transaction engine 210 and ensures that a malicious user cannot access or corrupt the 
transaction engine 210. 

The PB store 224 allows the merchant to purchase payment buttons and add product 

20 descriptions, merchant configurations, and other information to the database 212. In a 

preferred embodiment of the present invention, the merchant 1 12 accesses the PB store through 
a web site on the web server 214. The PB store module 224 captures the merchant 1 12 actions 
on the web server 214 and creates the appropriate entries in the database 212. 

In one embodiment of the present invention, the PB store web site describes the 

25 payment button mechanism, the services offered by the payment button vendor, and the costs 
of the services. In addition, the web site preferably has a merchant registration form 226 for 
registering new merchants, a merchant renewal form 228 for renewing merchant registrations, 
and a payment button generation form 230 for issuing payment buttons to registered 
merchants. The forms preferably include CGI programs for performing the functionality 

30 described herein. 

The merchant registration form 226 allows the merchant 1 12 to input information 
identifying the merchant 1 12 and includes a payment button with which the merchant 112 can 
pay a registration fee. After the fee payment is verified, the merchant 1 12 is preferably issued 
a login/password pair and an account with the CS 1 14 through which the merchant 1 12 can 
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access the payment button generation form and maintain the merchant's account. Similarly, 
the merchant renewal form 228 preferably includes a payment button with which the merchant 

1 1 2 can pay a renewal fee. 

The payment button generation form 230 allows the merchant 112 to enter item 

5 description data, such as item names and descriptions, prices, types, and delivery options, and 
payment processing rules, such as supported credit cards, payment systems, and currencies. In 
addition, the payment processing rules may rank the payment systems in order of preference, 
describe when payment is required (e.g., the merchant may require billing after 90 days), 
and/or describe the quantity or duration of an item available for a certain price. In one 

10 embodiment of the present invention, the merchant 112 enters the item description data and 
payment processing rules by uploading a file to web site having the information in a 
standardized format. 

When entry of this data is completed, the payment button generation form 230 sends 
the data to the transaction engine 210, which stores the information in the database 212 at a 
15 location specified by a key. The transaction engine 210 passes the key back to the PB store 
web site, which provides the merchant with a payment button download page displaying the 
results of the payment button generation transaction. If the transaction was successful, the 
payment button download page includes the payment button issued to the merchant 112. The 
payment button has an associated URL that specifies the key. Accordingly, little or no 
20 engineering effort is required to maintain each merchant configuration on the CS 1 14. 

In one embodiment of the present invention, there are multiple PB store web sites 
communicating with the database 212 through the transaction engine 210. When a payment 
button is created, the transaction engine 210 creates a field in the database 212 entry specifying 
the PB store that generated the payment button. Accordingly, payment buttons may be 
25 "branded" among different payment button vendors. 

The database 212 is preferably a robust relational database. A preferred embodiment of 
the present invention uses the ORACLE 7 database to implement the functionality described 
herein. The database 212 stores item descriptions, payment processing rules, and other 
information necessary to complete a payment transaction on behalf of a merchant 1 12. This 
30 merchant information is preferably accessed in the database by using a key assigned to each 
merchant 112 and/or item for sale. The database 212 is also used as a repository of transaction 
information including authorization logs, payment status and completion records, and other 
information required by the merchant 1 12 and the CS 1 14. 
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FIG. 3 is a high-level block diagram of functional components within the database 212. 
Illustrated therein are a database entry 300 including a primary entry 310 linked to at least one 
of three types of item entries 312, 314, 316. The primary entry 310 is the entry identified by 
the key provided to the merchant 112. Accordingly, the primary entry 310 is typically 

5 accessed either when the merchant 112 provides the key while using the PB store web site or 
when the customer 1 1 0 uses the URL provided by a payment button to purchase the item 
identified in the database entry 310. 

The primary entry 310 contains a field 318 storing the payment processing rules for the 
item as specified by the merchant 1 12 through the PB store. The primary entry 310 also 

1 0 contains a field 320 holding item type information as specified by the merchant 1 12. The item - 
type information preferably describes the item attributes input by the merchant 112. In 
addition, the item type information field 320 preferably contains at least one link to another 
database entry 312,314,316 describing delivery options for the item. 

The available delivery options for an item depend upon the type of item. FIG. 3 

1 5 illustrates three database entries 3 1 2, 3 14, 3 1 6 describing delivery options for hard, soft, and 
online items. However, an embodiment of the present invention may have many different 
types of items and corresponding delivery options. A hard item is typically a manufactured 
physical product such as clothing, a book, or a machine part. Accordingly, the entry 312 
holding delivery options 322 may list various shipping methods and companies available for 

20 delivering the hard item to the customer 110. 

A soft item, in contrast, is typically intangible intellectual property such as music, 
electronic books, or software. For example, the soft item may be a streaming music file that 
can be played by the customer 110. Accordingly, the entry 314 holding delivery options 324 
may list a URL or electronic key that can be provided to the customer to effectuate the 

25 purchase. For example, the options 324 may provide instructions for initiating an FTP session 
to download the purchased soft item to the customer's 1 10 computer system. 

An online item is typically access to an online service or other software executing 
remotely from the customer 1 10. For example, the online item may be access to an electronic 
database of information or an online game. Accordingly, the entry 316 holding delivery 

30 options 326 preferably includes instructions for allowing the customer 1 10 to access the online 
item. For example, the options 326 may provide instructions for initiating a telnet session with 
an electronic database for a limited duration of time. 

FIG. 4 is a flow diagram illustrating the interactions between the customer 1 1 0, 
merchant 1 12, CS 1 14, database 212 and a payment system 222 when completing a payment 

10 
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paction acting ,o aprefened embodimen. of .he presen. invention. In ft. How d,agram. 
time flows from me .op of the diagram .0 fee bonom and hor.zon.al line, represen, 
co.rununica.ions between .he various entities. FIG. 4 il.»stia,es only major infractions 
bemeen .he entities and does no. represen. evoy fraction. In addition FIG. 4 il.ustia.es a 
simple case of <»e presen, invention wherein the merchant 1 12 paymen, processmg rules 
specify ma, me pa^en. tiansaction should be processed a. me time .he corner's 110 order 
is received 

mitially .he customer .10 is browsing .he merchant web she and decides ,0 purchase 
an i,em by pressing 4.0 .he associa.ed paymen. bur.cn. In response .0 ,he press, .he 
merchant web server 1 12 redirecs 412 tine cus,omer's browser .0 .he locanon on .he CS 14 
specified by .he URL as.ocia.ed wi,h me paymen, bution. The customer's browser fe,ches 414 
the referenced page from the CS 1 1 4. 

The CS 1 14 parses the URL received from the customer 1 10 for the database 212 key 
corresponding to the Hem that the customer 110 wishes to purchase. Using this key, the CS 
1 14 accesses 416 the database 212 and dynamically generates a web page md.catmg the 
attributes and payment options available for the tan as defmed by the merchant 1 12 In 
addition, the CS 1 1 4 preferably determines the language utilized by the customer 1 
currencies supported by the merchant 1 12 and modifies the web page accordmgly. Tto. 
generated web page is sent 418 to the customer 110. FIG. 5 illustrates an exemplary screen 
, display 500 of the web page seeking payment information from the customer 110. 

The customer selects the desired item attributes and payment service, enters any 
necessary payment information, such as a credit card or account number, and transrmts 420 
these data to the CS 1 14. The CS 1 14 stores 422 the received data in the database 212 and 
contacts the selected payment system 222. As described above, the CS 1 14 preferably U ^ eS |^ 
5 PAPI module 220 to translate transaction calls made by the transaction engine 210 mto the API 
of the selected payment system 222. The CS 114 preferably stores 426 records of all 
communications with the payment system 222, customer 1 10, and merchant 1 12 m the 
database 212. Therefore, the database 212 can be used to reconstruct transaction htstones m 
order to provide error tracking and accounting services. If the payment system 222 rejects the 
0 transaction, the CS 1 14 publishes a web page to the customer indicating thts result and 
presenting alternative payment methods, if any (this interaction is not shown m FIG. 4). 

If the payment system 222 approves the transaction, the CS dynamically generates a 
web page containing payment status information and publishes 428 this informal to the 
customer 1 10. This page preferably contains a receipt or confirmation number generated by 
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the CS 1 14. In a preferred embodiment of the present invention, the confirmation number is a 
unique number encoding transaction, session, and merchant identifications and a time and date 
stamp. This confirmation number is preferably a key to a database entry holding the 
transaction information and can be used later by the merchant 1 1 2 and customer 1 1 0 to confirm 
5 payment, to query the CS 1 14 for payment status information, and to use the CS 1 14 to query 
the payment system for account status information; The web page also preferably contains any 
other information required by the merchant 1 12 and a link to a confirmation page on the 
merchant's web site 112. FIG. 6 illustrates an exemplary screen display 600 of an order 
confirmation web page. 

10 The CS 1 1 4 also notifies 428 the merchant 1 1 2 that payment was accepted and provides^ 

the same receipt or confirmation number as was provided to the customer 1 10. In one 
embodiment, this notification is performed via a secure electronic mail message. Accordingly, 
both the customer 1 10 and merchant 1 12 are notified that the purchase was made. 

Finally, the customer 1 1 0 fetches 430 the confirmation web page on the merchant's 

15 web site. Preferably, this web page provides the customer 110 with additional information 
about the purchase or any other information which the merchant 112 desires to provide. 

In summary, the present invention is a system, method, and computer program 
instructions for conducting electronic commerce transactions via the Internet or any electronic 
communication system. The merchant 112 opens an account on the CS 1 14 and supplies 

20 information about items sold by the merchant 1 12. The CS 1 14 stores this information in a 
database 212 entry and issues the merchant 112 a URL containing the key to database entry. 
The merchant 112 supplies this URL to customers wishing to purchase an item, causing a 
customer 1 10 to be connected to the CS 1 14. The CS 1 14. collects payment information from 
the customer 1 10, conducts the electronic commerce transaction with a remote payment system 

25 222, and notifies the customer 1 1 0 and merchant 1 12 of the result. 
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Claims 

1 claim: 

, . A computer system for supporting electron* commerce transactions between a 
customer and a remote merchant, the computer system comprising: 



a : 



a' 



a database having an entry including merchant information identifying an item 

offered for sale by the remote merchant; and 
a transaction engine in communication with the database and a remote payment 
system for performing an electronic commerce transaction, the transaction 
engine comprising: 

a first module for receiving an electronic commerce transaction identifier 
from the customer, the electronic commerce transaction identifier 
specifying the entry in the database; 
second module for accepting payment information from the customer, the 

payment information identifying the remote payment system; and 
third module for performing the electronic commerce transaction with the 
remote payment system using the payment information received 
from the customer. 

2. The computer system of claim 1 , wherein the transaction engine further 
comprises: 

a fourth module for notifying the remote merchant and the customer of a result of 
the electronic commerce transaction. 

3. The computer system of claim 1 , further comprising: 

a W eb server in communication with the transaction engine for communicating with 

the remote merchant and customer; and 
a firewall between the web server and the transaction engine for securing 

communications between the web server and the transaction engine. 

4. The computer system of claim 3, wherein the transaction engine further 
comprises: 

a fifth module for dynamically generating a web page from the entry in the database 
and providing the web page to the customer via the web server, the web 
page providing information about the item offered for sale by the remote 
13 
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merchant and facilitating collection of the payment information from the 
customer. ' 

5. The computer system of claim 3, wherein the computer system further 
comprises: 

a sixth module for accepting the merchant information identifying the item offered 
for sale by the remote merchant via the web server, creating the database 
entry for holding the merchant information, and providing the remote 
merchant with a reference to the database entry. 

6. The computer system of claim 1, wherein the electronic commerce transaction 
identifier is a URL identifying the computer system and including a key to the entry in the 
database. 

7. The computer system of claim 1, wherein the database further comprises: 

an entry specifying payment processing rules defined by the remote merchant; and 
an entry specifying delivery options for the item offered for sale by the remote 
merchant. 

8. The computer system of claim 1 , wherein there are a plurality of available 
remote payment systems and wherein the second module for accepting payment information 
from the customer accepts payment information identifying one of the available remote 
payment systems. 

9. The computer system of claim 1 , wherein the transaction engine is executed by 
a plurality of distributed computer systems. 

10. A method of conducting electronic commerce between a remote customer and a 
remote merchant, the method comprising the steps of: 

receiving information identifying an item to be purchased by the remote customer; 
receiving payment information specifying a payment method to be used by the 

remote customer to purchase the item; 
conducting a payment transaction with a remote payment system specified by the 

payment information; and 
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providing the remote customer and the remote merchant with a result of the 
payment transaction. 

11. The method of claim 1 0, further comprising the steps of: 

receiving information about the item to be purchased from the remote merchant; 
storing the information about the item to be purchased at a specified location; and 
providing the remote merchant with a reference to the specified location. 

1 2. The method of claim 1 1 , wherein the remote merchant provides the reference to 
the specified location to the remote customer responsive to the remote customer desiring to 
purchase the item. 

13. The method of claim 10, further comprising the step of: 

providing the remote customer with a list of item attributes from which the 
customer can select. 

14. The method of claim 1 0, wherein the step of receiving information identifying 
the item to be purchased by the remote customer comprises the steps of: 

receiving payment processing rules specifying payment options available for 

purchasing the item; and 
receiving delivery options for the item. 

1 5. A computer-readable medium having computer instructions encoded thereon for 
conducting electronic commerce transactions between a remote merchant and a remote 
customer, the computer instructions comprising: 

instructions for storing item information received from the remote merchant; 
instructions for issuing the remote merchant a reference to the stored item 
information; 

instructions for receiving an electronic commerce transaction identifier from the 
remote customer containing the reference to the stored item information 
issued to the remote merchant; 

instructions for accepting payment information from the remote customer, the 
payment information identifying a remote payment system; and 
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instructions for conducting the electronic commerce transaction with the remote 
payment system using the payment information received from the remote * 
customer. 

16. The computer-readable medium of claim 15, wherein the instructions further 
comprise: 

instructions for notifying the remote merchant and the remote customer of a result 
of the electronic commerce transaction. 

17. The computer-readable medium of claim 15, wherein the instructions for storing 
item information received from the remote merchant comprise: 

instructions for receiving payment processing rules from the remote merchant 

specifying payment options for the electronic commerce transaction; and 

instructions for receiving delivery rules from the remote merchant specifying 
delivery options for the electronic commerce transaction. 
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METHOD AND SYSTEM FOR CONDUCTING 
ELECTRONIC COMMERCE TRANSACTIONS 

Cross-Reference to Related Application 
This application is a continuation-in-part of U.S. Provisional Application No. 
60/054,121, filed July 29, 1997. 

Background 

Fin n of th f Invention 

This invention pertains in general to electronic commerce and in particular to a method 
and system for conducting electronic payment transactions via the Internet. 

R AfKGRQUN'n OF THE INVENTION 

Electronic commerce conducted over the Internet has become increasingly important 
over the last decade. Online merchants offer goods and services for sale or rent including 
physical objects such as compact disks, books, and clothing, and intellectual property such as 
streaming musk and movies and electronic books. Physical items may be delivered to the 
customer via the mail or a variety of other shipping options. Intellectual property, in contrast, 
may be delivered to the customer by allowing a download via the file transfer protocol 
("FTP"), providing the customer with an access key, establishing a telnet session, or through 
some other form of electronic delivery. 

Typically, these goods and services are displayed on the merchant's web site and a 
prospective customer views, selects, and purchases the goods using web browsing software 
such as NETSCAPE NAVIGATOR*. The customer usually pays for a product by establishing 
a secure connection with the merchant's web server and transmitting payment information, 
such as a credit card number, to the merchant. The merchant then uses back-end processing to 
verify the payment information and receive payment. For example, the merchant may use a 
secure telephone line or network link to contact the credit card issuer before accepting the 
customer's order. Eventually, the merchant and credit card issuer settle payment and the 
merchant delivers the product or service to the customer. 

A difficulty with the above-described scenario is that each merchant must implement an 
inventory and payment database and a payment acceptance and verification system. For 
example, the merchant must establish and maintain a database tracking sales, delivery, and 
payment information and product inventories in order to support the electronic commerce 
system. There is significant cost and complexity in maintaining this database, including the 
difficulty of integrating it with legacy accounting and fulfillment systems and aggravated by 
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the scarcity of truly skilled personnel. In addition, the merchant must design web pages to 
securely accept the order and payment information and implement the functionality to verify 
the payment. These tasks can be extremely difficult if the merchant accepts payment using 
many different methods, such as credit cards and electronic fund transfers, or accepts payment 

5 in more than one currency. Moreover, having a large number of separate payment acceptance 
systems on the Internet provides a greater opportunity for fraud and abuse because the flaws of 
each system can be exploited. 

Although Internet-based electronic commerce clearinghouses have been developed to 
handle transactions from many different parties, these clearinghouses do not provide a 

10 convenient interface to the merchant. In addition, the merchant must still establish the 
payment, verification, and database systems described above. 

Accordingly, there is a need in the art for a method and system for conducting 
electronic commerce on the Internet which reduces the amount of work that must be performed 
by the online merchant. Preferably, the method and system will allow the merchant to easily 

15 and verifiably perform inventory, sales, and delivery tracking and transparently support 
different types of payments and currencies. 

Summary of the Invention 

The above needs are met by a method and system for conducting electronic commerce 
20 transactions that allows a merchant to easily sell a mix of physical and intangible items and 

supports sales, inventory, and delivery tracking and a variety of payment systems by having the 
merchant establish an account on a commerce server. The commerce server provides the 
merchant with inventory, accounting, and order management systems. Furthermore, the 
commerce server allows merchants to conduct electronic commerce with other merchants and 
25 vendors. 

The commerce server includes a web server providing web pages to the merchant. By 
using these web pages, the merchant establishes an account on the commerce server. Then, the 
merchant provides the commerce server with information about an item sold by the merchant, 
such as a plane ticket, clothing, a book, a software product, or playing time with an online 
30 game. The merchant also provides the commerce server with other attributes of the item from 
which the customer may select, for example, the quantity or duration of an item. In addition, 
the merchant supplies payment processing rules defining the payment options that are 
acceptable to the merchant, such as which currencies and payment systems are allowed and 
when or how often to bill the customer. 
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The commerce server preferably stores the information received from the merchant in 
an entry of a database. In one embodiment, the database entry categorizes the item as a hard 
good, soft good, or online good depending upon the delivery options available for the item. 
The commerce server, in addition, provides the merchant with a "payment button" including a 
5 universal resource locator ("URL") that points to the commerce server and includes 
information allowing the commerce server to identify the database entry with which the 
payment button is associated. The merchant preferably publishes the payment button on the 
merchant's web site. 

The customer selects the payment button when the customer wishes to purchase the 
10 associated product. In response, the customer's computer is automatically directed to the web 
server managed by the commerce server and provided with the item information entered by the 
merchant. In addition, the customer is presented with the payment options allowed by the 
merchant's payment processing rules. Preferably, the customer then provides the web server 
with the payment information necessary to complete the transaction. 

When the merchant's payment terms specify that payment is required, the commerce 
server preferably identifies the remote payment system selected by the customer and contacts it 
to complete the electronic commerce transaction. Preferably, a module within the commerce 
server converts calls generated by the commerce server into the format used by the selected 
payment system. Likewise, the module converts responses received from the payment system 
into the format used by the commerce server. Then, the commerce server notifies the customer 
and the merchant of the result of the electronic commerce transaction and, if appropriate, 
delivers the item using one of the delivery options specified in the database. 

A method of conducting electronic commerce between a remote customer and a remote 
merchant in accordance with the present invention includes receiving information identifying 
25 an item to be purchased by the customer, receiving payment information specifying a payment 
method to be used by the customer to purchase the item, conducting a payment transaction 
with a remote payment system specified by the payment information, and providing the 
customer and the merchant with the result of the payment transaction. 

Similarly, computer program instructions for conducting electronic commerce 
30 transactions in accordance with the present invention include instructions for storing item 
information received from the merchant, instructions for issuing the merchant a reference to 
the stored item information, instructions for receiving an electronic commerce transaction 
identifier from the customer containing the reference to the stored item information issued to 
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the merchant, instructions for accepting payment information from the customer, and 
instructions for conducting the electronic commerce transaction with a remote payment system. 

Brief Description of the Drawings 
5 FIGURE 1 is a high-level block diagram of an electronic commerce system according 

to an embodiment of the present invention; 

FIGURE 2 is a high-level block diagram illustrating functional components of a 
commerce server according to an embodiment of the present invention; 

FIGURE 3 is a high-level block diagram of an entry in a database associated with the 
10 commerce seiner according to an embodiment of the present invention; 

FIGURE 4 is a flow diagram illustrating the interactions between the customer, 
merchant, commerce server, and payment system when completing a payment transaction 
according to an embodiment of the present invention; and 

FIGURE 5 illustrates an exemplary screen display of a web page seeking payment 
15 information from a customer; and . 

FIGURE 6 illustrates an exemplary screen display of an order confirmation web page. 

Detailed Description of the Preferred Embodiment 

As used herein, the "Internet" refers to the global network of interconnected computer 
20 systems and the "World Wide Web" ("WWW") refers to the global hypertext system using the 
Internet as its transport mechanism. A "universal resource locator" ("URL") is a reference to a 
piece of information or a software function on a computer connected to the Internet. A "web 
server" is a program that accepts requests for information framed according to the HyperText 
Transport Protocol ("HTTP"). "Web pages" are the information supplied by the web server in 
25 response to the requests. The Common Gateway Interface ("CGI") is the standard that 

describes how the web server accesses external programs, usually called "CGI programs" or 
"CGI scripts," called by a web page. Of course, the present invention is not limited to the 
Internet and may be used with any digital network supporting electronic commerce. In a non- 
Internet-based system, the terms defined above also include the non-Internet-based equivalents 
30 for communicating between the various entities described herein. 

FIG. 1 is a high-level block diagram of an electronic commerce system 100 according 
to an embodiment of the present invention. Illustrated are a customer computer (sometimes 
referred to as "the customer") 1 10, a merchant web server (sometimes referred to as "the 
merchant") 1 12, and a commerce server ("CS") 114, all coupled to the Internet 1 16. In a 
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typical embodiment, the customer computer 1 1 0 is a personal computer having, among other 
things, a processor, memory, storage device, and monitor. The customer computer 1 10 is 
coupled to the Internet 1 16 via a network connection 1 1 8. The network connection may be, for 
example, a modem coupled to an analog telephone line, a digital subscriber line, a cable 
modem utilizing bandwidth on a cable television coaxial cable, a high speed digital line, or any 
other communications medium. Web browsing software, such as NETSCAPE 
NAVIGATOR*, preferably executes on the client computer and sends data from the client 
computer 1 10 to the merchant web server 1 12 via the network connection 1 18 and Internet 
1 1 6. In another embodiment, the customer computer 1 1 0 is a palm-top device or personal 
digital system communicating via radio waves with the Internet 1 16 or another electronic 
commerce system. 

The merchant web server 1 12 is preferably similar to the customer computer 1 10 except 
that it is has the processing power and communications 1 16 bandwidth to handle multiple 
simultaneous customer transactions. The merchant 112 sells items, such as merchandise, 
information, intellectual property, and/or services via a web site hosted on the merchant web 
server 1 12. The merchant's 1 12 web site may, for example, display a catalog of software 
available for purchase, allow the customer 1 1 0 to view flight schedules and purchase a plane 
ticket, or allow the customer 1 10 to play an online game, download a book or music, or access 

a database of information. 

As used herein, the terms "customer" and "merchant" depend upon the specific 
transaction being conducted. In a chain of commerce transactions, the "customer" in a first 
transaction may be a "merchant" in a second transaction. For example, the customer 1 10 may 
buy components of a product from several different vendors or merchants 1 12 using the 
electronic commerce system described herein and then, in turn, sell the combined product via 
the customer's own web site and the CS 1 14. 

The merchant's web site displays at least one "payment button." A payment button is a 
graphic button, a region of a larger graphic, a text string, or another form of URL link which 
the customer 1 1 0 may "press" by selecting it with a mouse, physical button, or other input 
device. In another embodiment, the payment button may be utilized on a non-Intemet-based 
electronic commerce system. In such an embodiment, the payment button is considered to be 
"pressed" whenever a customer 110 expresses a desire to purchase an item. As described 
below, the payment button is pressed by the customer 1 10 when the customer 110 wishes to 
purchase and pay for an item displayed for sale on the merchant's web site. In a preferred 
embodiment, every type of item for sale on the merchant's web site has a separate payment 
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button. When a customer 1 10 wishes to purchase the product, the 1 10 customer presses the 
product's associated payment button. Then, the customer 1 10 is preferably presented with a 
menu allowing the customer 1 10 to specify attributes, such as quantity or duration, of the items 
that the customer 110 wishes to purchase. . 

5 In another embodiment, the merchant web site has only one payment button or has only 

one payment button for each class of items for sale. In this embodiment, the customer 1 10 is 
preferably presented with a menu of choices after pressing the payment button. For example, 
the menu of choices may ask the customer 1 10 to identify a specific product or an attribute of a 
product, like colon that the customer 1 10 wishes to purchase. 

10 Every payment button has an associated URL that points to information in the CS 114... 

Preferably, a database key that uniquely identifies the merchant 112 and/or item for sale is 
encoded within the URL. When the customer 110 presses the payment button, the customer 
110 is redirected to a web page provided by the CS 1 14 and specific to the merchant 1 12 
and/or item. 

15 In one embodiment, the CS 1 14 queries the customer for the quantity or duration of the 

item that the customer 110 wishes to purchase and payment information. The CS 1 14 receives 
the customer's responses and conducts the electronic commerce transaction according to 
payment processing rules and delivery options specified by the merchant 1 12. The CS 1 14 
records the transaction in its database and notifies the customer and merchant whether the 

20 transaction was successful. Accordingly, the merchant 1 12 is relieved of the responsibility of 
conducting the electronic commerce transaction with the customer 110. 

FIG. 2 is a high-level block diagram illustrating functional components of the CS 1 14 
and also illustrating a remote payment system 222 and a remote merchant 223 according to a 
preferred embodiment of the present invention. The CS 1 14 is preferably similar to the 

25 customer 1 1 0 and merchant 1 1 2 computers, except that the CS 1 1 4 has enough processing 
power and Internet 1 1 6 bandwidth to support many simultaneous payment button transactions 
as described herein. The functionality of the CS 1 14 described herein may be performed by 
hardware or software modules within the CS 114. In one embodiment of the present invention, 
the functionality of the CS 1 14 is provided by software applications executing on INTEL x86- 

30 or SUN MICROSYSTEMS SPARC-compatible hardware under control of MICROSOFT 
WINDOWS NT or a derivative of the UNIX operating system, such as SOLARIS 2.5.1. In 
another embodiment of the present invention, the functionality of the CS 1 14 is provided by a 
distributed computing system as described below. 
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The remote payment system 222 is preferably a third-party payment gateway or system. 
The gateway or system is preferably connected to a financial transaction network, which, in 
turn, typically links to computers at banks and other financial institutions for approval and 
settlement of electronic commerce transactions. Typical gateways or systems may include 
5 CYBERCASH, e-CASH, MONDEX, or SET. While only one payment system 222 is 
illustrated in FIG. 2, the CS 1 14 may be in communication with many different remote 
payment systems 222, either through a secure link on the Internet 1 1 6 or a dedicated secure 
link. Each payment system has an applications programming interface ("API")- By using the 
API, the CS 1 14 communicates with the payment system 222 and performs secure and 
1 0 verifiable payment transactions. 

The remote merchant 223 is preferably a merchant selling items via a web site as 
described above. The remote merchant 223 may have an account on the CS 1 14 or the 
merchant 223 may have an interface for selling items similar to the remote payment system 
222. In general, the remote merchant 223 is included in FIG. 2 to illustrate that the customer's 
15 110 electronic commerce transaction performed by the CS 1 14 may contact a remote payment 
system 222 and/or a remote merchant 223. 

The CS 1 14 includes a payment button transaction engine 210 which is coupled to a 
database 212 and a web server 214. A firewall 216 preferably sits between the web server 216 
and the transaction engine 210. While these functional components are illustrated in FIG. 2 as 
20 discrete entities, the CS 1 1 4 may be executed on a distributed computer system having a 
plurality of engines, databases, and web servers working together the perform the functions 
described herein. For example, one embodiment of the CS 1 14 uses multiple transaction 
engines 210 and web servers 214 and a single distributed database 212, thereby providing 
scalability to the CS 1 14. The number of web servers 214 and transaction engines 210 depends 
25 on the actual system load and the desire to achieve better performance through balancing the 
transaction load across the system. 

The payment button transaction engine 210 includes a rules module 218 that controls 
the interactions and flows of information necessary to complete a payment transaction. In 
addition, the transaction engine 210 preferably includes a Payment Application Programming 
30 Interface ("P API") module 220 enabling communication between the CS 1 14 and the remote 
payment systems 222 and merchants 223. The PAPI module 220 abstracts the different APIs 
of each payment system 222 and merchant 223 into a single, higher level, PAPI that can 
interface with each of the payment systems 222 and merchants 223. The transaction engine 
210 performs payment transactions with a payment system 222 or merchant 223 by making 
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calls to the PAPI. The PAPI abstraction module 220 translates these calls into the specific API 
of the payment system 222 or merchant 223 being used for that transaction. The PAPI 
abstraction module 220 also translates data received from the payment system 222 or merchant 
223 into the format utilized by the transaction engine 210. Accordingly, the PAPI abstraction 
5 module 220 allows support for new payment systems 222 and merchants 223 to be added to the 
CS 1 14 by merely creating a new PAPI to payment system or merchant API mapping in the 
PAPI abstraction module 220. 

The payment button store module ("PB store") 224, in combination with the web server 
214, allows a merchant 1 12 to obtain a payment button. The web server 214 is preferably an 
10 industry- standard web server such as the NETSCAPE ENTERPRISE SERVER or the 

APACHE web server. The web server 214 provides secure communication with the customer 
1 10 and preferably uses industry standard technologies including HyperText Markup Language 
("HTML"), and HTTP to deliver information to the customer 110. In addition, the web server 
preferably uses industry standard encryption techniques, including secure HTTP ("S-HTTP") 
15 and the secure sockets layer ("SSL"), to ensure that communications with the customer 1 10 are 
private. The firewall 216 allows only authorized communications between the web server 214 
and the transaction engine 210 and ensures that a malicious user cannot access or corrupt the 
transaction engine 210. 

The PB store 224 allows the merchant to purchase payment buttons and add product 
20 descriptions, merchant configurations, and other information to the database 212. In a 

preferred embodiment of the present invention, the merchant 112 accesses the PB store through 
a web site on the web server 214. The PB store module 224 captures the merchant 112 actions 
on the web server 214 and creates the appropriate entries in the database 212. 

In one embodiment of the present invention, the PB store web site describes the 
25 payment button mechanism, the services offered by the payment button vendor, and the costs 
of the services. In addition, the web site preferably has a merchant registration form 226 for 
registering new merchants, a merchant renewal form 228 for renewing merchant registrations, 
and a payment button generation form 230 for issuing payment buttons to registered 
merchants. The forms preferably include CGI programs for performing the functionality 
30 described herein. 

The merchant registration form 226 allows the merchant 1 12 to input information 
identifying the merchant 1 12 and includes a payment button with which the merchant 1 12 can 
pay a registration fee. After the fee payment is verified, the merchant 1 12 is preferably issued 
a login/password pair and an account with the CS 1 14 through which the merchant 1 12 can 
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access the payment button generation form and maintain the merchant's account. Similarly, 
the merchant renewal form 228 preferably includes a payment button with which the merchant 
1 12 can pay a renewal fee. 

The payment button generation form 230 allows the merchant 1 12 to enter item 

5 description data, such as item names and descriptions, prices, types, and delivery options, and 
payment processing rules, such as supported credit cards, payment systems, and currencies. In 
addition, the payment processing rules may rank the payment systems in order of preference, 
describe when payment is required (e.g., the merchant may require billing after 90 days), 
and/or describe the quantity or duration of an item available for a certain price. In one 

10 embodiment of the present invention, the merchant 1 12 enters the item description data and 
payment processing rules by uploading a file to web site having the information in a 
standardized format. 

When entry of this data is completed, the payment button generation form 230 sends 
the data to the transaction engine 210, which stores the information in the database 212 at a 
1 5 location specified by a key. The transaction engine 2 1 0 passes the key back to the PB store 
web site, which provides the merchant with a payment button download page displaying the 
results of the payment button generation transaction. If the transaction was successful, the 
payment button download page includes the payment button issued to the merchant 1 12. The 
payment button has an associated URL that specifies the key. Accordingly, little or no 
20 engineering effort is required to maintain each merchant configuration on the CS 1 14. 

In one embodiment of the present invention, there are multiple PB store web sites 
communicating with the database 212 through the transaction engine 210. When a payment 
button is created, the transaction engine 210 creates a field in the database 212 entry specifying 
the PB store that generated the payment button. Accordingly, payment buttons may be 
25 "branded" among different payment button vendors. 

The database 212 is preferably a robust relational database. A preferred embodiment of 
the present invention uses the ORACLE 7 database to implement the functionality described 
herein. The database 212 stores item descriptions, payment processing rules, and other 
information necessary to complete a payment transaction on behalf of a merchant 112. This 
30 merchant information is preferably accessed in the database by using a key assigned to each 
merchant 112 and/or item for sale. The database 212 is also used as a repository of transaction 
information including authorization logs, payment status and completion records, and other 
information required by the merchant 1 12 and the CS 1 14. 
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FIG. 3 is a high-level block diagram of functional components within the database 212. 
Illustrated therein are a database entry 300 including a primary entry 310 linked to at least one 
of three types of item entries 312, 314, 316. The primary entry 310 is the entry identified by 
the key provided to the merchant 112. Accordingly, the primary entry 3 1 0 is typically 
accessed either when the merchant 112 provides the key while using the PB store web site or 
when the customer 1 10 uses the URL provided by a payment button to purchase the item 
identified in the database entry 310. 

The primary entry 3 1 0 contains a field 3 1 8 storing the payment processing rules for the 
item as specified by the merchant 1 1 2 through the PB store. The primary entry 3 1 0 also 
contains a field 320 holding item type information as specified by the merchant 112. The- item- 
type information preferably describes the item attributes input by the merchant 112. In 
addition, the item type information field 320 preferably contains at least one link to another 
database entry 312,314,316 describing delivery options for the item. 

The available delivery options for an item depend upon the type of item. FIG. 3 
illustrates three database entries 312, 314, 316 describing delivery options for hard, soft, and 
online items. However, an embodiment of the present invention may have many different 
types of items and corresponding delivery options. A hard item is typically a manufactured 
physical product such as clothing, a book, or a machine part. Accordingly, the entry 312 
holding delivery options 322 may list various shipping methods and companies available for 
delivering the hard item to the customer 110. 

A soft item, in contrast, is typically intangible intellectual property such as music, 
electronic books, or software. For example, the soft item may be a streaming music file that 
can be played by the customer 110. Accordingly, the entry 314 holding delivery options 324 
may list a URL or electronic key that can be provided to the customer to effectuate the 
purchase. For example, the options 324 may provide instructions for initiating an FTP session 
to download the purchased soft item to the customer's 110 computer system. 

An online item is typically access to an online service or other software executing 
remotely from the customer 110. For.example, the online item may be access to an electronic 
database of information or an online game. Accordingly, the entry 316 holding delivery 
options 326 preferably includes instructions for allowing the customer 1 10 to access the online 
item. For example, the options 326 may provide instructions for initiating a telnet session with 
an electronic database for a limited duration of time. 

FIG. 4 is a flow diagram illustrating the interactions between the customer 110, 
merchant 1 12, CS 114, database 212 and a payment system 222 when completing a payment 
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transaction according to a preferred embodiment of the present invention. In the flow diagram, 
time flows from the top of the diagram to the bottom and horizontal lines represent 
communications between the various entities. FIG. 4 illustrates only major interactions 
between the entities and does not represent every interaction. In addition, FIG. 4 illustrates a 
simple case of the present invention wherein the merchant's 112 payment processing rules 
specify that the payment transaction should be processed at the time the customer's 110 order 
is received. 

Initially, the customer 1 1 0 is browsing the merchant's web site and decides to purchase 
an item by pressing 410 the associated payment button. In response to the press, the 
merchant's web server 112 redirects 412 the customer's browser to the location on the CS 1 14 
specified by the URL associated with the payment button. The customer's browser fetches 41 4 

the referenced page from the CS 1 14. 

The CS 1 14 parses the URL received from the customer 1 10 for the database 212 key 
corresponding to the item that the customer 1 10 wishes to purchase. Using this key, the CS 
114 accesses 416 the database 212 and dynamically generates a web page indicating the 
attributes and payment options available for the item as defined by the merchant 1 12. In 
addition, the CS 1 14 preferably determines the language utilized by the customer 1 10 and 
currencies supported by the merchant 1 12 and modifies the web page accordingly. This 
generated web page is sent 41 8 to the customer 1 1 0. FIG. 5 illustrates an exemplary screen 
display 500 of the web page seeking payment information from the customer 1 1 0. 

The customer selects the desired item attributes and payment service, enters any 
necessary payment information, such as a credit card or account number, and transmits 420 
these data to the CS 1 14. The CS 1 14 stores 422 the received data in the database 212 and 
contacts the selected payment system 222. As described above, the CS 1 14 preferably uses the 
PAP1 module 220 to translate transaction calls made by the transaction engine 210 into the API 
of the selected payment system 222. The CS 1 14 preferably stores 426 records of all 
communications with the payment system 222, customer 1 10, and merchant 1 12 in the 
database 212. Therefore, the database 212 can be used to reconstruct transaction histories in 
order to provide error tracking and accounting services. If the payment system 222 rejects the 
transaction, the CS 1 14 publishes a web page to the customer indicating this result and 
presenting alternative payment methods, if any (this interaction is not shown in FIG. 4). 

If the payment system 222 approves the transaction, the CS dynamically generates a 
web page containing payment status information and publishes 428 this information to the 
customer 1 10. This page preferably contains a receipt or confirmation number generated by 
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the CS 1 14. In a preferred embodiment of the present invention, the confirmation number is a 
unique number encoding transaction, session, and merchant identifications and a time and date 
stamp. This confirmation number is preferably a key to a database entry holding the 
transaction information and can be used later by the merchant 1 12 and customer 1 10 to confirm 
5 payment, to query the CS 1 1 4 for payment status information, and to use the CS 1 14 to query 
the payment system for account status information. The web page also preferably contains any 
other information required by the merchant 1 12 and a link to a confirmation page on the 
merchant's web site 1 12. FIG. 6 illustrates an exemplary screen display 600 of an order 
confirmation web page. 

10 - The CS 1 14 also notifies 428 the merchant 1 12 thatpayment was accepted and provides- 
the same receipt or confirmation number as was provided to the customer 110. In one 
embodiment, this notification is performed via a secure electronic mail message. Accordingly, 
both the customer 1 10 and merchant 1 12 are notified that the purchase was made. 

Finally, the customer 1 10 fetches 430 the confirmation web page on the merchant's 

15 web site. Preferably, this web page provides the customer 1 10 with additional information 
about the purchase or any other information which the merchant 1 12 desires to provide. 

In summary, the present invention is a system, method, and computer program 
instructions for conducting electronic commerce transactions via the Internet or any electronic 
communication system. The merchant 112 opens an account on the CS 1 14 and supplies 

20 information about items sold by the merchant 112. The CS 1 14 stores this information in a 
database 212 entry and issues the merchant 112 a URL containing the key to database entry. 
The merchant 1 12 supplies this URL to customers wishing to purchase an item, causing a 
customer 1 10 to be connected to the CS 114. The CS 1 14 collects payment information from 
the customer 1 10, conducts the electronic commerce transaction with a remote payment system 

25 222, and notifies the customer 1 10 and merchant 1 12 of the result. 
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Claims 

1 claim: 

1 . A computer system for supporting electronic commerce transactions between a 
customer and a remote merchant, the computer system comprising: 

a database having an entry including merchant information identifying an item 

offered for sale by the remote merchant; and 
a transaction engine in communication with the database and a remote payment 
system for performing an electronic commerce transaction, the transaction 
engine comprising: 

a first module for receiving an electronic commerce transaction identifier 

from the customer, the electronic commerce transaction identifier 

specifying the entry in the database; 
a second module for accepting payment information from the customer, the 

payment information identifying the remote payment system; and 
a third module for performing the electronic commerce transaction with the 

remote payment system using the payment information received 

from the customer. 

2. The computer system of claim 1, wherein the transaction engine further 
comprises: 

a fourth module for notifying the remote merchant and the customer of a result of 
the electronic commerce transaction. 

3. The computer system of claim 1 , further comprising: 

a web server in communication with the transaction engine for communicating with 

the remote merchant and customer; and 
a firewall between the web server and the transaction engine for securing 

communications between the web server and the transaction engine. 

4. The computer system of claim 3, wherein the transaction engine further 
comprises: 

a fifth module for dynamically generating a web page from the entry in the database 
and providing the web page to the customer via the web server, the web 
page providing information about the item offered for sale by the remote 
13 
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merchant and facilitating collection of the payment information from the 
customer. 

5. The computer system of claim 3, wherein the computer system further 
comprises: 

a sixth module for accepting the merchant information identifying the item offered 
for sale by the remote merchant via the web server, creating the database 
entry for holding the merchant information, and providing the remote 
merchant with a reference to the database entry. 

6. The computer system of claim 1 , wherein the electronic commerce transaction 
identifier is a URL identifying the computer system and including a key to the entry in the 
database. 

7. The computer system of claim 1 , wherein the database further comprises: 

an entry specifying payment processing rules defined by the remote merchant; and 
an entry specifying delivery options for the item offered for sale by the remote 
merchant. 

8. The computer system of claim 1 , wherein there are a plurality of available 
remote payment systems and wherein the second module for accepting payment information 
from the customer accepts payment information identifying one of the available remote 
payment systems. 

9. The computer system of claim 1 , wherein the transaction engine is executed by 
a plurality of distributed computer systems. 

10. A method of conducting electronic commerce between a remote customer and a 
remote merchant, the method comprising the steps of: 

receiving information identifying an item to be purchased by the remote customer; 
receiving payment information specifying a payment method to be used by the 

remote customer to purchase the item; 
conducting a payment transaction with a remote payment system specified by the 

payment information; and . 
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providing the remote customer and the remote merchant with a result of the 
payment transaction. 

11. The method of claim 1 0, further comprising the steps of: 

receiving information about the item to be purchased from the remote merchant; 
storing the information about the item to be purchased at a specified location; and 
providing the remote merchant with a reference to the specified location. 

12. The method of claim 1 1, wherein the remote merchant provides the reference to 
the specified location to the remote customer responsive to the remote customer desiring to 
purchase the item. 

13. The method of claim 10, further comprising the step of: 

providing the remote customer with a list of item attributes from which the 
customer can select. 

14. The method of claim 10, wherein the step of receiving information identifying 
the item to be purchased by the remote customer comprises the steps of: 

receiving payment processing rules specifying payment options available for 

purchasing the item; and 
receiving delivery options for the item. 

15. A computer-readable medium having computer instructions encoded thereon for 
conducting electronic commerce transactions between a remote merchant and a remote 
customer, the computer instructions comprising: 

instructions for storing item information received from the remote merchant; 
instructions for issuing the remote merchant a reference to the stored item 
information; 

instructions for receiving an electronic commerce transaction identifier from the 
remote customer containing the reference to the stored item information 
issued to the remote merchant; 

instructions for accepting payment information from the remote customer, the 
payment information identifying a remote payment system; and 
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instructions for conducting the electronic commerce transaction with the remote 
payment system using the payment information received from the remote 
customer. 

16. The computer-readable medium of claim 15, wherein the instructions further 
5 comprise: 

instructions for notifying the remote merchant and the remote customer of a result 
of the electronic commerce transaction. 

17. The computer-readable medium of claim 15, wherein the instructions for storing 
item information received from the remote merchant comprise: 

10 instructions for receiving payment processing rules from the remote merchant 

specifying payment options for the electronic commerce transaction; and 
instructions for receiving delivery rules from the remote merchant specifying 
delivery options for the electronic commerce transaction. 
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PAYMENT DETAILS 



PLEASE REVIEW THIS PAGE AND ENSURE IT IS CORRECT, 
BEFORE COMPLETING YOUR PAYMENT DETAILS. 




SKU QTY ITEMS 
2121 2 SPROCKET 



UNIT PRICE EXTENDED PRICE 
$8.99 $17.98 
SUBTOTAL: $17.98 
SHIPPING: $ 3.95 
TAX: $ 1-72 

TOTAL: $23.65 



BILLING ADDRESS 



SHIPPING ADDRESS 



FIRST NAME: 
LAST NAME: 
COMPANY: 
ADDRESS 1: 
ADDRESS2: 
CITY: 
STATE: 
ZIP: 



JOE 

BLOGGS 

GLOBAL BAKING COMPANY 
2252 N. PETERS RD. 

SAN JOSE 
CA 

96025-5123 



PAYMENT INFORMATION 



PAYMENT TYPE: 

NAMEAS IT APPEARS ON CARD » 
NUMBER 

EXPIRATION DATE 



MASTERCARD 




♦I l/I 

| MAKE CORRECTIONS | | PROCESS ORDfcK | 
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6/6 



netadvantage 1 
ii 

--THANK YOU FOR YOUR ORDER - - 
RECEIPT NUMBER: 1 587-8029-5 

GLOBAL SPROKETS COMPANY INC. 

2243 E. WISTENA WAY, BOSTON, MA 24248, USA 

EMAIL: INFO@SPROKETS.COM. WEB: HTTP//WWW.SPROKETS.COM 

I : PRODUCTS ORDERED \ 



SKU QTY ITEMS 
2121 2 SPROCKET 



UNIT PRICE TOTAL PRICE 
$8.99 $17.98 
SUBTOTAL: $17.98 
SHIPPING: $ 3.95 
TAX: $ 1.72 

TOTAL: $23.65 



BILLING ADDRESS 



SHIPPING ADDRESS 



FIRST NAME: 
LAST NAME: 
COMPANY: 
ADDRESS 1: 
ADDRESS2: 
CITY: 
STATE: 
ZIP: 



JOE 

BLOGGS 

GLOBAL BAKING COMPANY 
2252 N. PETERS RD. 

SAN JOSE 
CA 

96025-5123 



PAYMENT INFORMATION 



PAYMENT TYPE: MASTERCARD 
YOUR CARD HAS BEEN CHARGED: $23.65 



CUSTOMER INFORMATION 



WE AIM TO SHIP ITEMS WITHIN 10 DAYS 
THANK YOU FOR YOUR ORDER! 
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